Para garantir a continuidade dos negócios e minimizar a perda de dados, a alta disponibilidade (HA, na sigla em inglês) e a recuperação de desastres (DR, na sigla em inglês) 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 do tempo de recuperação (RTO), enquanto a DR aborda a recuperação de eventos catastróficos e a minimização do objetivo do ponto de recuperação (RPO).
O RTO e o RPO estão alinhados aos requisitos de negócios e são definidos da seguinte maneira:
- 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.
- RPO é a quantidade máxima de perda de dados que uma empresa pode sofrer antes que isso afete os requisitos de negócios. Por exemplo, os sistemas de inventário que exigem uma trilha de auditoria completa podem ter um requisito de perda de dados zero.
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 a replicação zonal e regional (HA e DR).
Mecanismos de disponibilidade
A seguir, confira 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 diferentes equilíbrios 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 do sistema, uma estratégia de backup robusta precisa incluir backups de banco de dados e de arquivos de registro prévio de escrita (WAL, na sigla em inglês). Backups regulares (normalmente diários) de arquivos de dados são essenciais. Também é necessário fazer backup de arquivos WAL, que registram modificações no banco de dados e são essenciais para a recuperação point-in-time e para manter a integridade dos dados durante a restauração.
Réplica do banco de dados
O PostgreSQL oferece servidores de réplica para maior confiabilidade. Essas réplicas são classificadas como standbys quentes, que não aceitam conexões de aplicativos, ou standbys ativos, que operam 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 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 para mitigar 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 nessas configurações.
Em implantações de alta disponibilidade, as réplicas geralmente são implantadas perto do banco de dados principal. Por exemplo, as réplicas implantadas em uma zona diferente no mesmo data center oferecem RTOs baixos e RPO quase zero. Por outro lado, nas configurações de recuperação de desastres, as réplicas são implantadas em data centers ou regiões separados, dependendo do nível de proteção necessário 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 para as arquiteturas de referência de disponibilidade do AlloyDB Omni:
| Recurso | Padrão | Aprimorado | Premium |
|---|---|---|---|
| Backup | ✔ | ✔ | ✔ |
| Réplica zonal | ❌ | ✔ | ✔ |
| Réplica entre zonas | ❌ | ✔ | ✔ |
| Réplica regional | ❌ | ❌ | ✔ |
Tabela 1. Mecanismos de disponibilidade do AlloyDB Omni com suporte
Falhas de banco de dados e cenários de recuperação
A falha do banco de dados pode ocorrer nos seguintes níveis:
- Falha da 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 regional: 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 desses eventos 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 oferecem suporte:
| Tipo de desastre | Padrão | Aprimorado | Premium |
|---|---|---|---|
| Falha de VM/instância | ✔ | ✔ | ✔ |
| Falha de nó/servidor | ✔ | ✔ | ✔ |
| Falha na zona | ❌ | ✔ | ✔ |
| Falha regional | ❌ | ❌ | ✔ |
Tabela 2. Cenários de recuperação com suporte
Considere seus objetivos de negócios para o banco de dados do AlloyDB Omni, como uma necessidade crítica de vários 9s (99,99%) de disponibilidade e perda de dados zero após a recuperação de aplicativos essenciais. 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, aprimorada e premium para proteger bancos de dados contra interrupções planejadas e não planejadas, alinhadas a diferentes necessidades de negócios. 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 aprimorada).
- Proteja seus dados usando a replicação zonal e regional (disponibilidade premium).