Compreendendo e Executando Cenários de Failover vs. Switchover no PostgreSQL

Na arquitetura de banco de dados moderna, garantir a operação contínua por meio da Alta Disponibilidade (HA) é fundamental. O PostgreSQL, um poderoso banco de dados relacional de código aberto, depende da replicação de streaming para manter a consistência dos dados em vários nós. No entanto, quando o servidor primário encontra um problema ou requer manutenção, os administradores de banco de dados devem executar procedimentos precisos para restaurar o serviço. Este artigo diferencia claramente duas operações críticas de HA — Failover (Comutação por Falha) e Switchover (Comutação Planejada) — e detalha as etapas e considerações para promover com segurança um réplica de espera para se tornar o novo primário.

Entender a distinção entre esses eventos é vital. Um switchover é uma transição planejada e controlada, enquanto um failover é uma resposta de emergência a uma interrupção inesperada. O sucesso em navegar em qualquer um dos cenários depende muito da configuração adequada, monitoramento robusto e familiaridade com as ferramentas usadas para gerenciar a replicação.

Fundamentos da Replicação: A Base da HA

A Alta Disponibilidade do PostgreSQL é construída sobre a replicação de streaming, onde um servidor atua como Primário (ou Mestre) e um ou mais servidores atuam como Standbys (ou Réplicas). O Primário transmite registros de log de escrita antecipada (WAL) para os Standbys para mantê-los sincronizados.

Para gerenciar esses papéis de forma eficaz, configurações específicas são necessárias nos nós primário e de réplica:

Configurações Críticas

Estas configurações governam como a replicação opera e como os nós se identificam:

• wal_level: Deve ser definido como replica ou superior (idealmente logical se estiver usando ferramentas que exigem decodificação lógica) no Primário.
• max_wal_senders: Define o número máximo de conexões simultâneas dos standbys. Deve ser aumentado em relação ao padrão (geralmente 10) para acomodar todos os standbys.
• hot_standby: Deve ser definido como on no postgresql.conf do servidor standby para permitir consultas de apenas leitura durante a replicação.
• synchronous_commit: Controla o reconhecimento da transação. Para perda de dados zero durante switchovers, este valor é frequentemente definido como on (ou remote_write para tolerância a latência menor).
• primary_conninfo: Definido no standby, detalhando as informações de conexão (host, porta, usuário, senha) para se conectar ao Primário atual.

Melhor Prática: Para HA robusta, use camadas de pool de conexão (como PgBouncer ou proxies de HA dedicados como Patroni ou Repmgr) que abstraem os endereços físicos dos servidores, tornando failovers e switchovers transparentes para as aplicações.

Switchover: A Transição Planejada

Um Switchover (Comutação Planejada) é um processo controlado e elegante onde o nó Primário ativo é intencionalmente desativado, e um Standby designado é promovido para assumir seu lugar. Este procedimento é tipicamente usado para manutenção planejada, atualizações de versão ou substituições de hardware.

Etapas para um Switchover Controlado

O objetivo de um switchover é garantir perda zero de dados, esperando que todas as transações em andamento sejam replicadas antes da promoção.

1. Parar Gravações no Primário Atual: O primeiro passo é impedir que novas transações sejam confirmadas no Primário atual. Isso é frequentemente alcançado definindo default_transaction_read_only = on ou desligando temporariamente as conexões do cliente.
2. Aguardar Sincronização da Replicação: Garanta que o Standby designado tenha recebido e aplicado todos os registros WAL restantes do Primário. Você pode verificar o atraso da replicação usando pg_stat_replication no Primário ou examinando o status de recuperação do standby.
3. Iniciar a Promoção do Standby: Execute o comando para promover o servidor Standby escolhido para o papel de Primário. O comando específico depende da ferramenta de gerenciamento usada (por exemplo, pg_ctl promote ou um comando de gerenciador de cluster).
4. Reconfigurar o Primário Antigo: Assim que o Standby for promovido com sucesso, o antigo Primário deve ser reconfigurado para seguir o novo Primário como um Standby. Isso envolve a atualização de seu primary_conninfo.
5. Redirecionar Aplicações: Atualize o balanceador de carga ou o pooler de conexão para direcionar o tráfego para o novo servidor Primário.

Failover: A Resposta de Emergência

Failover (Comutação por Falha) é um procedimento imediato e reativo acionado quando o servidor Primário atual falha inesperadamente (por exemplo, falha de hardware, partição de rede, erro de software) e não pode ser colocado online rapidamente.

Failover inerentemente carrega um risco maior de perda de dados, pois não há garantia de que as últimas transações confirmadas tiveram tempo de ser transmitidas para os Standbys antes que a falha ocorresse.

Executando um Failover de Emergência

Os procedimentos de Failover são projetados para velocidade e recuperação, muitas vezes utilizando ferramentas especializadas para automatizar a promoção.

1. Determinar a Saúde do Primário Antigo: Verifique se o Primário original está verdadeiramente indisponível e não apenas passando por um problema de rede transitório (isso evita cenários perigosos de 'split-brain').
2. Selecionar o Melhor Standby: Escolha o Standby com o menor atraso de replicação (aquele que está mais adiantado no fluxo WAL).
3. Promover o Standby: Promova imediatamente o Standby selecionado usando o comando de promoção (pg_ctl promote).
4. Lidar com Perda de Dados (Se Necessário): Se o cluster utilizar replicação assíncrona, os dados perdidos no Primário com falha podem precisar ser reconciliados manualmente ou simplesmente aceitos, dependendo da tolerância da aplicação.
5. Reconfigurar o Antigo Primário: Assim que o Primário original for recuperado, ele deve ser limpo, reinicializado (muitas vezes exigindo um backup base do novo Primário) e configurado para seguir o novo Primário.

Ferramentas para Promoção Segura: Repmgr vs. Patroni

Embora a promoção manual usando pg_ctl seja possível, ambientes de HA robustos dependem de ferramentas dedicadas para gerenciar a coreografia complexa necessária para failover e switchover, lidando automaticamente com alterações de configuração e gerenciamento do estado do cluster.

Repmgr (Replication Manager)

repmgr é uma ferramenta poderosa e leve que monitora a replicação e facilita o failover manual ou automático. Os comandos principais incluem:

• Switchover: repmgr standby promote seguido por repmgr switchover --sibling-nodes-wait (para garantir a sincronização).
• Failover: repmgr failover

Patroni

Patroni utiliza Lojas de Consenso Distribuído (como etcd, ZooKeeper ou Consul) para gerenciar o estado do cluster, elegendo automaticamente um novo Primário após a detecção de falha. Patroni automatiza em grande parte tanto switchovers quanto failovers por meio de chamadas de API ou operadores Kubernetes, reduzindo drasticamente a intervenção manual.

Exemplo usando Patroni (Comando de Promoção Conceitual):

# Acionando um switchover via API REST do Patroni
curl -X POST http://ponto-final-api-patroni/switchover -H "Content-Type: application/json" -d '{"target": "nome_do_nó_standby"}'

Aviso sobre Split-Brain: O maior perigo durante o failover automático é o cenário de 'split-brain', onde dois nós erroneamente acreditam ser o Primário devido a particionamento de rede. Ferramentas como Patroni mitigam isso usando mecanismos de quorum, enquanto configurações manuais exigem mecanismos de isolamento (fencing) rigorosos (como controles de energia) para garantir que exista apenas um Primário.

Resumo das Diferenças

Executar failovers e switchovers no PostgreSQL requer uma compreensão profunda do estado do cluster e das ferramentas que o gerenciam. Enquanto os switchovers visam perda zero de dados por meio de coordenação, os failovers priorizam a restauração rápida do serviço, muitas vezes ao custo das transações mais recentes. A configuração adequada dos parâmetros de replicação e a utilização de ferramentas robustas de gerenciamento de cluster são os pilares da Alta Disponibilidade confiável do PostgreSQL.