Nesta página, descrevemos a alta disponibilidade e as ferramentas que recomendamos usar.
Sobre a capacidade de recuperação de dados
Pense na capacidade de recuperação 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, seu 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, ou RTO. 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 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) junto com metas de 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 o pgBackRest e também arquiva os arquivos de registro de gravação antecipada (WAL) 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 e garantir que cada transação confirmada no primário 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 perda de dados. Por exemplo, é possível ter um RPO diferente de zero em troca de menor latência transacional 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 de 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). No entanto, 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 de uma região com vários data centers próximos, o AlloyDB Omni pode ser configurado com replicação de transmissão assíncrona da região primária para uma região secundária, geralmente a centenas ou milhares de quilômetros de distância ou com uma diferença de dezenas a centenas de milissegundos. Nessa configuração, a região principal é configurada com replicação de streaming síncrona entre os bancos de dados principal e em 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 a alta disponibilidade de bancos de dados podem variar dependendo do sistema de gerenciamento de banco de dados. Confira 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 banco de dados:
Redundância: replicar o 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 automático: mecanismo para detectar falhas e alternar sem problemas 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 de dados: implementamos salvaguardas para proteger a integridade dos dados durante falhas. Isso inclui técnicas de replicação e verificações de consistência de dados.
Clustering: envolve agrupar vários servidores de banco de dados para trabalharem 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.
Substituição: métodos para substituir a arquitetura original usando nós de pré-failover principal e de réplica nas capacidades originais.
Balanceamento de carga: distribuir solicitações de banco de dados entre várias instâncias melhora o desempenho e lida com 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 automáticos de failover.
Backup e restauração: os backups podem ser usados para restaurar bancos de dados a um estado anterior em caso de corrupção de dados ou falha catastrófica.
Pool de conexões (opcional): otimiza a performance 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ído, 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 ao lado do 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ído (DCS) 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 proxy de alta disponibilidade (HAProxy) é um software de código aberto usado para balanceamento de carga e proxy de aplicativos baseados em TCP e HTTP. Ele é 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 entre 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 vai parar 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 do PostgreSQL gerenciado pelo Patroni, a replicação pode ser configurada nos modos síncrono e assíncrono. Por padrão, o Patroni usa replicação de streaming assíncrona. Para requisitos de RPO rigorosos, recomendamos usar a 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 standby síncrono antes de serem confirmadas. A replicação síncrona garante que os dados não sejam perdidos em caso de falha primária, oferecendo alta durabilidade e consistência. A principal aguarda confirmações do standby síncrono, o que pode levar a maior latência e menor capacidade devido ao tempo de ida e volta adicionado. Isso pode reduzir a taxa de transferência geral do sistema, especialmente em alta carga.
A replicação assíncrona permite que as transações sejam confirmadas no cluster principal sem esperar o reconhecimento dos clusters em espera. A principal envia registros de WAL para as secundárias, 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 servidor principal falhar antes que o standby seja atualizado. Os standbys podem estar atrás do principal, causando possíveis inconsistências durante o failover.
A escolha entre replicação síncrona e assíncrona em um cluster do 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 menor latência são priorizados. É possível configurar uma solução mista que envolva um cluster de três nós com um standby síncrono na mesma região, mas em uma zona ou data center próximo diferente, e um segundo standby assíncrono em uma região diferente ou um data center mais distante para proteger contra possíveis interrupções regionais.