Nesta página, apresentamos as arquiteturas de disponibilidade do AlloyDB Omni que podem ser usadas para garantir que o banco de dados do AlloyDB Omni seja restaurado de maneira oportuna com pouca ou nenhuma perda de dados.
Para garantir a continuidade dos negócios e minimizar a perda de dados, a alta disponibilidade (HA) e a recuperação de desastres (DR) são estratégias de proteção de dados essenciais para o AlloyDB Omni. A HA se concentra em manter a disponibilidade do banco de dados e minimizar o objetivo de tempo de recuperação (RTO), enquanto a DR aborda a recuperação de eventos catastróficos e a minimização do objetivo de ponto de recuperação (RPO).
O RTO e o RPO estão alinhados aos requisitos de negócios e são definidos da seguinte forma:
- O RTO é o tempo máximo que um banco de dados pode ficar inativo ou indisponível antes que a empresa sofra consequências inaceitáveis, como perda de receita ou produtividade.
- O RPO é a quantidade máxima de perda de dados que uma empresa pode sofrer antes de afetar os requisitos de negócios. Por exemplo, sistemas de inventário que exigem uma trilha de auditoria completa podem ter um requisito de perda zero de dados.
O AlloyDB Omni oferece as seguintes arquiteturas de referência de disponibilidade que fornecem níveis crescentes de disponibilidade:
- Disponibilidade padrão: protege seus dados usando backups.
- Disponibilidade aprimorada: protege seus dados usando a replicação zonal em uma região (HA).
- Disponibilidade Premium: protege seus dados usando replicação zonal e regional (HA e DR).
Mecanismos de disponibilidade
Estes são os principais mecanismos que garantem a disponibilidade:
- Backups de banco de dados
- Réplica do banco de dados
Backups de banco de dados
Os backups de banco de dados, um aspecto fundamental da proteção de dados, envolvem a criação de cópias físicas dos arquivos de dados do banco de dados. Diferentes tipos de backup (completo, incremental e diferencial) oferecem saldos variados entre o objetivo de ponto de recuperação (RPO), o tamanho e a duração do backup e o tempo de restauração.
Para garantir uma recuperação eficiente e minimizar a perda de dados em caso de falhas no sistema, uma estratégia de backup robusta precisa incluir backups de banco de dados e de arquivos de registro de gravação antecipada (WAL, na sigla em inglês). É fundamental fazer backups regulares (geralmente diários) dos arquivos de dados. Também é necessário fazer backup dos arquivos WAL, que registram modificações no banco de dados e são essenciais para a recuperação pontual e a manutenção da integridade dos dados durante a restauração.
Réplica do banco de dados
O PostgreSQL oferece servidores de réplica para aumentar a confiabilidade. Essas réplicas são classificadas como espera ativa, que não aceita conexões de aplicativos, ou espera ativa, que opera no modo somente leitura. As mudanças do banco de dados principal são aplicadas continuamente à réplica para manter os dados dela atualizados. Se o banco de dados principal falhar, a réplica será promovida ao status de principal e assumirá as responsabilidades do banco de dados principal.
As réplicas de banco de dados podem ser colocadas na mesma zona ou data center da instância principal, em uma zona diferente, em uma região diferente ou em uma combinação desses locais. Quanto mais distante a réplica estiver do banco de dados principal, maior será a latência ao enviar mudanças para manter as réplicas atualizadas. Para implantações em locais distantes que mitigam falhas em grande escala, como falhas regionais, a replicação de dados geralmente é feita de forma assíncrona. Essa abordagem evita a degradação de desempenho que pode ocorrer em tais configurações.
Em implantações de alta disponibilidade, as réplicas geralmente são implantadas perto do banco de dados principal. Por exemplo, réplicas implantadas em uma zona diferente no mesmo data center oferecem RTOs baixos e RPO próximo de zero. Por outro lado, em configurações de recuperação de desastres, as réplicas são implantadas em data centers ou regiões separadas, dependendo do nível necessário de proteção contra interrupções. Essa abordagem resulta em um RPO mais alto (já que a replicação pode ser assíncrona) e um RTO variado.
A tabela a seguir resume os mecanismos usados nas arquiteturas de referência de disponibilidade do AlloyDB Omni:
| Recurso | Padrão | Aprimorada | Premium |
|---|---|---|---|
| Backup | ✔ | ✔ | ✔ |
| Réplica zonal | ❌ | ✔ | ✔ |
| Réplica entre zonas | ❌ | ✔ | ✔ |
| Réplica regional | ❌ | ❌ | ✔ |
Tabela 1. Mecanismos de disponibilidade do AlloyDB Omni compatíveis
Falhas de banco de dados e cenários de recuperação
A falha do banco de dados pode ocorrer nos seguintes níveis:
- Falha na instância (nó ou servidor): o próprio banco de dados falha.
- Falha do servidor: o servidor que hospeda o banco de dados falha.
- Falha zonal: todo o data center que abriga o servidor falha.
- Falha na região: toda a região que contém vários data centers (zonas de disponibilidade) fica indisponível, por exemplo, devido a uma enchente ou um terremoto de grande magnitude.
A probabilidade e o risco de um desastre diminuem quando há menos eventos e o custo de prevenção aumenta. As empresas precisam determinar a tolerância a riscos e escolher se aceitam possíveis interrupções ou investem em arquiteturas mais resilientes para minimizar os riscos.
A tabela a seguir resume os cenários de recuperação que as arquiteturas de referência do AlloyDB Omni aceitam:
| Tipo de desastre | Padrão | Aprimorada | Premium |
|---|---|---|---|
| Falha na VM/instância | ✔ | ✔ | ✔ |
| Falha no nó/servidor | ✔ | ✔ | ✔ |
| Falha na zona | ❌ | ✔ | ✔ |
| Falha regional | ❌ | ❌ | ✔ |
Tabela 2. Cenários de recuperação compatíveis
Considere os objetivos de negócios do seu banco de dados AlloyDB Omni, como uma necessidade crítica de vários 9s (99,99%) de disponibilidade e perda zero de dados na recuperação para aplicativos de missão crítica. O objetivo das arquiteturas de referência de disponibilidade é atender aos requisitos de RTO e RPO.
O AlloyDB Omni oferece arquiteturas de disponibilidade padrão, avançada e premium para proteger bancos de dados contra interrupções planejadas e não planejadas, alinhando-se a diferentes necessidades comerciais. Por exemplo, ambientes de desenvolvimento podem usar proteção básica com backups, enquanto aplicativos essenciais podem empregar configurações de alta disponibilidade e recuperação de desastres.
A seguir
Saiba mais sobre as arquiteturas de referência de disponibilidade do AlloyDB Omni:
- Proteja seus dados usando backups (disponibilidade padrão).
- Proteja seus dados usando a replicação zonal em uma região (disponibilidade avançada).
- Proteja seus dados usando a replicação zonal e regional (disponibilidade Premium).