Para garantir a continuidade da empresa e minimizar a perda de dados, a alta disponibilidade (AD) e a recuperação de desastres (RD) são estratégias de proteção de dados cruciais para o AlloyDB Omni. A HA centra-se na manutenção da disponibilidade da base de dados e na minimização do 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 com os requisitos empresariais e são definidos da seguinte forma:
- O RTO é o tempo máximo durante o qual uma base de dados pode estar inativa ou indisponível antes de a empresa sofrer 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 de afetar os requisitos empresariais. Por exemplo, os sistemas de inventário que requerem uma trilha de auditoria completa podem ter um requisito de zero perda de dados.
O AlloyDB Omni oferece as seguintes arquiteturas de referência de disponibilidade que proporcionam níveis de disponibilidade crescentes:
- Disponibilidade padrão: protege os seus dados através de cópias de segurança.
- Disponibilidade melhorada: protege os seus dados através da replicação zonal numa região (HA).
- Disponibilidade premium: protege os seus dados através da replicação zonal e regional (HA e DR).
Mecanismos de disponibilidade
Seguem-se os principais mecanismos que garantem a disponibilidade:
- Cópias de segurança de bases de dados
- Replicação de base de dados
Cópias de segurança de bases de dados
As cópias de segurança de bases de dados, um aspeto fundamental da proteção de dados, envolvem a criação de cópias físicas de ficheiros de dados da base de dados. Os diferentes tipos de cópias de segurança (completa, incremental e diferencial) oferecem diferentes equilíbrios entre o objetivo de ponto de recuperação (OPR), o tamanho e a duração da cópia de segurança, e o tempo de restauro.
Para garantir uma recuperação eficiente e minimizar a perda de dados em caso de falhas do sistema, uma estratégia de cópia de segurança robusta tem de incluir cópias de segurança da base de dados e do ficheiro de registo de transações (WAL). As cópias de segurança regulares (normalmente diárias) dos ficheiros de dados são cruciais. Também tem de fazer uma cópia de segurança dos ficheiros WAL, que registam as modificações da base de dados e são essenciais para a recuperação num determinado momento e para manter a integridade dos dados durante o restauro.
Replicação de base de dados
O PostgreSQL oferece servidores de réplica para maior fiabilidade. Estas réplicas são classificadas como standbys warm, que não aceitam ligações de aplicações, ou standbys hot, que funcionam num modo só de leitura. As alterações da base de dados principal são aplicadas continuamente à réplica para manter os dados da réplica atualizados. Se a base de dados principal falhar, a réplica é promovida ao estado principal e assume as responsabilidades da base de dados principal.
As réplicas da base de dados podem ser colocadas na mesma zona ou centro de dados que a instância principal, numa zona diferente, numa região diferente ou numa combinação destas localizações. Quanto mais longe a réplica estiver localizada da base de dados principal, maior é a latência ao enviar alterações para manter as réplicas atualizadas. Para implementações em localizações distantes, de modo a mitigar falhas em grande escala, como falhas regionais, a replicação de dados é normalmente feita de forma assíncrona. Esta abordagem evita a degradação do desempenho que pode ocorrer nestas configurações.
Nas implementações de alta disponibilidade, as réplicas são normalmente implementadas perto da base de dados principal. Por exemplo, as réplicas implementadas numa zona diferente no mesmo centro de dados oferecem RTOs baixos e um RPO próximo de zero. Por outro lado, nas configurações de recuperação de desastres, as réplicas são implementadas em centros de dados ou regiões separados, consoante o nível de proteção necessário contra interrupções. Esta abordagem resulta num OPR mais elevado (uma vez que a replicação pode ser assíncrona) e num OTR variado.
A tabela seguinte resume os mecanismos usados para as arquiteturas de referência de disponibilidade do AlloyDB Omni:
| Funcionalidade | Padrão | Melhorado | Premium |
|---|---|---|---|
| cópia de segurança | ✔ | ✔ | ✔ |
| Réplica zonal | ❌ | ✔ | ✔ |
| Réplica entre zonas | ❌ | ✔ | ✔ |
| Réplica regional | ❌ | ❌ | ✔ |
Tabela 1. Mecanismos de disponibilidade do AlloyDB Omni suportados
Falhas da base de dados e cenários de recuperação
A falha da base de dados pode ocorrer nos seguintes níveis:
- Falha da instância (nó ou servidor): a própria base de dados falha.
- Falha do servidor: o servidor que aloja a base de dados falha.
- Falha zonal: todo o centro de dados que aloja o servidor falha.
- Falha na região: toda a região que contém vários centros de dados (zonas de disponibilidade) está indisponível, por exemplo, devido a uma inundação ou a um terramoto de grande magnitude.
A probabilidade e o risco de um desastre diminuem quando existem menos eventos e o custo de prevenção destes eventos aumenta. As empresas têm de determinar a sua tolerância ao risco e escolher se aceitam potenciais interrupções ou investem em arquiteturas mais resilientes para minimizar os riscos.
A tabela seguinte resume os cenários de recuperação suportados pelas arquiteturas de referência do AlloyDB Omni:
| Tipo de desastre | Padrão | Melhorado | Premium |
|---|---|---|---|
| Falha de VM/instância | ✔ | ✔ | ✔ |
| Falha do nó/servidor | ✔ | ✔ | ✔ |
| Falha da zona | ❌ | ✔ | ✔ |
| Falha regional | ❌ | ❌ | ✔ |
Tabela 2. Cenários de recuperação suportados
Considere os objetivos da sua empresa para a base de dados AlloyDB Omni, como uma necessidade crítica de vários 9s (99,99%) de disponibilidade e zero perda de dados na recuperação para aplicações críticas. O objetivo das arquiteturas de referência de disponibilidade é satisfazer os requisitos de RTO e RPO.
O AlloyDB Omni oferece arquiteturas de disponibilidade padrão, melhorada e premium para proteger as bases de dados contra interrupções planeadas e não planeadas, alinhando-se com as várias necessidades empresariais. Por exemplo, os ambientes de desenvolvimento podem usar a proteção básica com cópias de segurança, enquanto as aplicações críticas podem usar configurações de alta disponibilidade e recuperação de desastres.
O que se segue?
Saiba mais sobre as arquiteturas de referência de disponibilidade do AlloyDB Omni:
- Proteja os seus dados através de cópias de segurança (disponibilidade padrão).
- Proteja os seus dados através da replicação zonal numa região (disponibilidade melhorada).
- Proteja os seus dados através da replicação zonal e regional (disponibilidade premium).