Esta página descreve a alta disponibilidade e as ferramentas que recomendamos usar.
Sobre a resiliência de dados
Pense na resiliência de dados em termos de disponibilidade, tempo de restauração do 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 uma disponibilidade de 99,99%, 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. O volume de perda de dados aceitável devido a uma interrupção é chamado de objetivo do ponto de recuperação, ou RPO, e é expresso como o 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), 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, defina 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 falhar, 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 mais rígidos de RPO e RTO, é possível configurar o AlloyDB Omni em uma configuração de alta disponibilidade usando o Patroni. Nesta arquitetura, há um banco de dados principal e dois 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 gravada no primário seja replicada de forma síncrona nos 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 arriscar uma pequena quantidade de perda de dados. Por exemplo, é possível ter um RPO diferente de zero em troca de uma latência de transação mais baixa, implementando alta disponibilidade com a replicação assíncrona em vez da 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 / menos de 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 a replicação assíncrona de streaming da região principal para uma secundária, normalmente a centenas ou milhares de quilômetros de distância ou de 10 a 100 milissegundos. Nessa configuração, a região principal é configurada com a 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 uma failover da região principal.
Como a alta disponibilidade funciona
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 a seguir 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 caso uma instância principal falhe.
Failover automatizado: mecanismo para detectar falhas e alternar facilmente para uma réplica saudável, 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 proteções são implementadas para proteger a integridade dos dados durante falhas. Isso inclui técnicas de replicação e verificações de consistência de dados.
Cluster: agrupar vários servidores de banco de dados para trabalhar juntos como um único sistema. Dessa forma, todos os nós no cluster estão ativos e processam solicitações, o que fornece balanceamento de carga e redundância.
Alternativa: métodos para voltar à 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 em várias instâncias melhora a performance e lida com o aumento de tráfego.
Monitoramento e alertas: as ferramentas de monitoramento detectam problemas como falha do servidor, alta latência, esgotamento de recursos e alertas de acionamento ou procedimentos de failover automático.
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 o desempenho e a escalabilidade dos aplicativos que interagem com seus bancos de dados.
Ferramentas de alta disponibilidade
O Patroni é uma ferramenta de gerenciamento de cluster de código aberto para bancos de dados PostgreSQL projetada para gerenciar e automatizar a alta disponibilidade de clusters 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 com o serviço do PostgreSQL em instâncias do servidor de banco de dados, gerenciando a integridade, as 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 uma loja de configuração distribuída (DCS, na sigla em inglês) chamada etcd. Um dos usos do etcd é armazenar e extrair 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 TCP e baseados em HTTP, usado para melhorar o desempenho e a confiabilidade de aplicativos da Web distribuindo as 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 aos quais ele se conecta, executando 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 a replicação de streaming assíncrona. Para requisitos estritos de RPO, 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 primário e em pelo menos um standby síncrono antes da confirmação. A replicação síncrona garante que os dados não sejam perdidos em caso de falha principal, oferecendo durabilidade e consistência. A primária aguarda confirmações do modo de espera síncrono, o que pode levar a uma latência maior e, possivelmente, a uma capacidade menor devido ao tempo de ida e volta adicionado. Isso pode reduzir a taxa de transferência geral do sistema, especialmente sob alta carga.
A replicação assíncrona permite que as transações sejam confirmadas no cluster principal sem aguardar confirmações de clusters de reserva. A principal envia registros de WAL para as 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 vem com o risco de perda de dados se o primário falhar antes que o reserva tenha sido atualizado. Os standbys podem estar atrás do primário, o que pode causar inconsistências durante o failover.
A escolha entre a replicação síncrona e assíncrona em um cluster Patroni depende dos requisitos específicos de durabilidade, consistência e desempenho de dados. A replicação síncrona é preferível em cenários em que a integridade e a perda mínima de dados são essenciais, enquanto a replicação assíncrona é adequada para ambientes em que a prioridade é o desempenho e a latência mais baixa. É possível configurar uma solução mista que envolve ter um cluster de três nós com um standby síncrono na mesma região, mas uma zona ou um data center próximo diferente e um segundo standby assíncrono em uma região diferente ou um data center mais distante para se proteger contra possíveis falhas regionais.