Esta página descreve a alta disponibilidade e as ferramentas que recomendamos usar.
Sobre a resiliência de dados
É possível pensar na resiliência de dados em termos de disponibilidade, tempo para restaurar o serviço e perda de dados. A disponibilidade geralmente é medida em termos de tempo de atividade e expressa como a porcentagem de tempo em que o banco de dados está disponível. Por exemplo, para alcançar 99,99% de disponibilidade, o banco de dados não pode ficar inativo por mais de 52,6 minutos por ano ou 4,38 minutos por mês. O tempo para restaurar o serviço após uma interrupção é chamado de objetivo de tempo de recuperação (RTO, na sigla em inglês). A quantidade aceitável de perda de dados devido a uma interrupção é chamada de objetivo do ponto de recuperação (RPO, na sigla em inglês) e é expressa como o período de tempo em que as transações são perdidas. Por exemplo, um RPO de 10 minutos significa que, em caso de falha, você pode perder até 10 minutos de dados.
É comum definir uma meta de disponibilidade ou objetivo de nível de serviço (SLO, na sigla em inglês), juntamente com metas para RTO e RPO. Por exemplo, para uma determinada carga de trabalho, você pode definir o SLO como 99,99% e também exigir um RPO de 0, sem perda de dados em nenhuma falha e um RTO de 30 segundos. Para outra carga de trabalho, você pode definir o SLO como 99,9%, o RPO como 5 minutos e o RTO como 10 minutos.
É possível implementar a resiliência básica do banco de dados com backups. O AlloyDB Omni oferece suporte a backups usando pgBackRest e também arquiva os arquivos de registro de gravação antecipada (WAL, na sigla em inglês) do banco de dados para minimizar a perda de dados. Com essa abordagem, se o banco de dados principal ficar inativo, ele poderá ser restaurado de um backup com um RPO de minutos e um RTO de minutos a horas, dependendo do tamanho do banco de dados.
Para requisitos de RPO e RTO mais rigorosos, é possível configurar o AlloyDB Omni em uma configuração de alta disponibilidade usando o Patroni. Nessa arquitetura, há um banco de dados principal e dois bancos de dados de espera ou réplica. É possível configurar o AlloyDB Omni para usar a replicação de streaming padrão do PostgreSQL para garantir que cada transação confirmada no banco de dados principal seja replicada de forma síncrona para os dois bancos de dados de espera. Isso fornece um RPO de zero e um RTO de menos de 60 segundos para a maioria dos cenários de falha.
Dependendo da configuração do cluster, a replicação síncrona pode afetar o tempo de resposta das transações, e você pode optar por arriscar uma pequena quantidade de perda de dados. Por exemplo, é possível ter um RPO diferente de zero em troca de uma latência transacional menor implementando alta disponibilidade com replicação assíncrona em vez de síncrona. Devido ao possível impacto da replicação síncrona na latência da transação, as arquiteturas de alta disponibilidade são quase sempre implementadas em um único data center ou entre data centers próximos (dezenas de quilômetros de distância / <10 milissegundos de latência de distância). No entanto, observe que esta documentação usa a replicação síncrona como padrão.
Para recuperação de desastres, que é a proteção contra a perda de um data center ou uma região em que há vários data centers próximos, o AlloyDB Omni pode ser configurado com replicação de streaming assíncrona da região principal para uma região secundária, normalmente centenas ou milhares de quilômetros de distância ou dezenas a centenas de milissegundos de distância. Nessa configuração, a região principal é configurada com replicação de streaming síncrona entre os bancos de dados principal e de espera na região, e a replicação de streaming assíncrona é configurada da região principal para uma ou mais regiões secundárias. O AlloyDB Omni pode ser configurado na região secundária com várias instâncias de banco de dados para garantir que ele seja protegido imediatamente após um failover da região principal.
Como funciona a alta disponibilidade
As técnicas e ferramentas específicas usadas para implementar alta disponibilidade para bancos de dados podem variar dependendo do sistema gerenciamento de bancos de dados. A seguir, apresentamos algumas das técnicas e ferramentas geralmente envolvidas na implementação de alta disponibilidade para bancos de dados, que podem variar dependendo do sistema de gerenciamento de bancos de dados:
Redundância: a replicação do banco de dados em vários servidores ou regiões geográficas oferece opções de failover se uma instância principal ficar inativa.
Failover automatizado: mecanismo para detectar falhas e alternar perfeitamente para uma réplica íntegra, minimizando o tempo de inatividade. As consultas são roteadas para que as solicitações de aplicativos cheguem ao novo nó principal.
Continuidade dos dados: as salvaguardas são implementadas para proteger a integridade de dados durante falhas. Isso inclui técnicas de replicação e verificações de consistência de dados.
Clustering: o clustering envolve o agrupamento de vários servidores de banco de dados para trabalhar juntos como um único sistema. Dessa forma, todos os nós do cluster ficam ativos e processam solicitações, o que fornece balanceamento de carga e redundância.
Fallback: métodos para retornar à arquitetura original usando nós principais e de réplica de pré-failover nas capacidades originais.
Balanceamento de carga: a distribuição de solicitações de banco de dados em várias instâncias melhora o desempenho e processa o aumento do tráfego.
Monitoramento e alertas: as ferramentas de monitoramento detectam problemas como falha do servidor, alta latência, esgotamento de recursos e acionam alertas ou procedimentos de failover automático.
Backup e restauração: os backups podem ser usados para restaurar bancos de dados para um estado anterior em caso de corrupção de dados ou falha catastrófica.
Pool de conexões (opcional): otimiza o desempenho e a escalonabilidade de aplicativos que interagem com seus bancos de dados.
Ferramentas de alta disponibilidade
O Patroni é uma ferramenta de gerenciamento de clusters de código aberto para bancos de dados PostgreSQL projetada para gerenciar e automatizar a alta disponibilidade de clusters do PostgreSQL. O Patroni usa vários sistemas de consenso distribuídos, como etcd, Consul, ou Zookeeper para coordenar e gerenciar o estado do cluster. Alguns dos principais recursos e componentes do Patroni incluem alta disponibilidade com failover automático, eleição de líder, replicação e recuperação. O Patroni é executado junto com o serviço PostgreSQL em instâncias de servidor de banco de dados, gerenciando a integridade, os failovers e a replicação para garantir alta disponibilidade e confiabilidade.
O Patroni usa um sistema de consenso distribuído para armazenar metadados e gerenciar o cluster. Neste guia, usamos um armazenamento de configuração distribuída (DCS, na sigla em inglês) chamado etcd. Um dos usos do etcd é armazenar e recuperar informações de sistemas distribuídos, como configuração, integridade e status atual, garantindo uma configuração consistente em todos os nós.
O High Availability Proxy (HAProxy) é um software de código aberto usado para balanceamento de carga e proxy de aplicativos baseados em TCP e HTTP, usado para melhorar o desempenho e a confiabilidade de aplicativos da Web distribuindo solicitações recebidas em vários servidores. O HAProxy oferece balanceamento de carga distribuindo o tráfego de rede em vários servidores. O HAProxy também mantém o estado de integridade dos servidores de back-end a que se conecta realizando verificações de integridade. Se um servidor falhar em uma verificação de integridade, o HAProxy para de enviar tráfego para ele até que ele passe nas verificações de integridade novamente.
Considerações sobre replicação síncrona e assíncrona
Em um cluster PostgreSQL gerenciado pelo Patroni, a replicação pode ser configurada nos modos síncrono e assíncrono. Por padrão, o Patroni usa a replicação de streaming assíncrona. Para requisitos de RPO rigorosos, recomendamos o uso da replicação síncrona.
A replicação síncrona no PostgreSQL garante a consistência dos dados aguardando que as transações sejam gravadas no banco de dados principal e em pelo menos um banco de dados de espera síncrono antes de serem confirmadas. A replicação síncrona garante que os dados não sejam perdidos em caso de falha principal, oferecendo forte durabilidade e consistência de dados. O banco de dados principal aguarda confirmações do banco de dados de espera síncrono, o que pode levar a uma latência maior e, possivelmente, a uma capacidade de processamento menor devido ao tempo de retorno adicional. Isso pode reduzir a capacidade de processamento geral do sistema, especialmente sob carga alta.
A replicação assíncrona permite que as transações sejam confirmadas no cluster principal sem aguardar confirmações de clusters de espera. O banco de dados principal envia registros WAL para bancos de dados de espera, que os aplicam de forma assíncrona. Essa abordagem assíncrona reduz a latência de gravação e melhora o desempenho, mas apresenta o risco de perda de dados se o banco de dados principal falhar antes que o banco de dados de espera seja atualizado. Os bancos de dados de espera podem estar atrás do banco de dados principal, levando a possíveis inconsistências durante o failover.
A escolha entre replicação síncrona e assíncrona em um cluster Patroni depende dos requisitos específicos de durabilidade, consistência e desempenho dos dados. A replicação síncrona é preferível em cenários em que a integridade dos dados e a perda mínima de dados são essenciais, enquanto a replicação assíncrona é adequada para ambientes em que o desempenho e a latência menor são priorizados. É possível configurar uma solução mista que envolve um cluster de três nós com um banco de dados de espera síncrono na mesma região, mas uma zona ou data center próximo diferente, e um segundo banco de dados de espera assíncrono em uma região diferente ou um data center mais distante para proteger contra possíveis interrupções regionais.