O que é a Streaming Replication (WAL) do PostgreSQL e como configurá-la

• A Streaming Replication do PostgreSQL é uma forma eficiente de manter uma ou mais réplicas quase em tempo real do banco de dados primário em servidores standby
• O servidor primário transmite continuamente os registros do Write-Ahead Log (WAL) para os servidores standby à medida que são gerados, minimizando o atraso no processo de replicação
• Foi projetada para melhorar alta disponibilidade e escalabilidade, permitindo descarregar consultas de leitura para os servidores standby e reduzir a carga no servidor primário
• Suporta modos síncrono e assíncrono, permitindo ajustar com flexibilidade o equilíbrio entre consistência dos dados e desempenho
• Inclui o processo em que o servidor standby se conecta ao primário para solicitar o streaming do WAL e aplica os registros recebidos à sua própria cópia do banco de dados
• Em comparação com o envio de logs baseado em arquivos, oferece failover mais rápido e menor risco de perda de dados, sendo ideal para ambientes geograficamente distribuídos

Como a Streaming Replication funciona?

• Os dados do WAL são transmitidos contínua e quase em tempo real do servidor primário para o servidor standby, mantendo o banco de dados do standby quase idêntico ao do primário
• Isso permite usar réplicas para failover do master ou para processar cargas de leitura, possibilitando escalar o sistema várias vezes

Arquivos de configuração do PostgreSQL e seus locais

• Os arquivos de configuração do PostgreSQL desempenham um papel importante no gerenciamento das configurações e do comportamento do servidor de banco de dados.
  • postgresql.conf: principal arquivo de configuração que contém a maior parte das configurações do servidor. Dependendo do sistema operacional, pode estar em diferentes locais, como /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) ou /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS)
  • pg_hba.conf: controla a autenticação de clientes e define como os clientes se conectam ao servidor. Normalmente fica no mesmo diretório de postgresql.conf
  • pg_ident.conf: usado para mapeamento de nomes de usuário, embora seja menos utilizado
  • recovery.conf: era usado para configurar servidores standby em versões anteriores ao PostgreSQL 12, mas nas versões posteriores seu conteúdo foi movido para postgresql.conf e postgresql.auto.conf
• A localização exata pode variar conforme o sistema operacional, o método de instalação e a versão do PostgreSQL
  • Você pode usar o comando SQL SHOW config_file; para localizar esses arquivos dentro da instância do PostgreSQL

Exemplo e estrutura do WAL (Write Ahead Logs)

• É possível visualizar o WAL com o comando pg_waldump
• Cada linha representa um registro WAL com informações sobre uma operação do banco de dados
• Componentes de cada registro:
  • rmgr: gerenciador de recursos (por exemplo, Heap, Btree, Transaction)
  • len: comprimento do registro
  • tx: ID da transação
  • lsn: Log Sequence Number
  • prev: LSN anterior
  • desc: descrição da operação
• Tipos de operação visíveis:
  • operações INSERT (Heap e Btree)
  • operações MULTI_INSERT (Heap2)
  • transações COMMIT
  • operações de arquivo (CREATE)
  • Full Page Writes (FPW)
• A saída do WAL mostra em detalhes o fluxo das transações, modificações de dados e atividade do sistema, sendo útil para analisar o comportamento do banco de dados, solucionar problemas e fazer recuperação pontual

Como trabalhar com Docker

• Configurações importantes relacionadas à Streaming Replication em postgresql.conf:
  • wal_level, max_wal_senders, max_replication_slots, hot_standby etc.
• Itens necessários para o exemplo com Docker Compose:
  • init-master.sh: configura o master do PostgreSQL para replicação. Cria usuário e slot de replicação e atualiza as configurações relacionadas ao WAL
  • init-replica.sh: prepara a réplica do PostgreSQL para se conectar ao master e iniciar a replicação. Aguarda até que o master esteja pronto, executa um backup base e configura a réplica
  • start-replica.sh: inicia a réplica do PostgreSQL no contêiner Docker. Executa o script init-replica.sh e depois inicia o PostgreSQL
  • docker-compose.yml: define os serviços do master e da réplica e configura as variáveis de ambiente, volumes, comandos etc. necessários
• Após conceder permissão de execução aos scripts, execute docker-compose up -d para iniciar o master e a réplica
• É possível verificar o status da replicação conectando-se ao master e consultando pg_stat_replication
• É possível confirmar se a réplica está em modo de recuperação conectando-se a ela e executando pg_is_in_recovery()

Opinião do GN⁺

• A Streaming Replication pode melhorar significativamente o desempenho e a resiliência da infraestrutura de banco de dados. Seja para cenários de failover ou para distribuir a carga de leitura entre réplicas, ela ajuda o banco de dados a escalar e manter desempenho estável
• Mostrar todo o processo de configuração e sua saída é importante. Isso oferece uma visão abrangente das muitas partes envolvidas e ajuda a entender melhor o que está acontecendo
• Entender como a Streaming Replication funciona e configurá-la corretamente é muito importante. Espera-se que este artigo tenha esclarecido esse processo e oferecido insights sobre como a replicação funciona
• Outros produtos ou projetos com funcionalidades semelhantes incluem o Replication do MySQL e o Data Guard da Oracle. Essas soluções também funcionam enviando alterações do master para as réplicas, embora os detalhes de implementação possam variar
• Ao usar Streaming Replication, é preciso considerar largura de banda e latência de rede. A transferência de dados entre master e réplica pode consumir recursos de rede de forma significativa. A escalabilidade do número de réplicas também é um ponto importante
• Os requisitos de consistência dos dados também devem ser avaliados. A replicação síncrona pode afetar o desempenho de escrita, mas oferece consistência mais forte. A replicação assíncrona oferece melhor desempenho, mas há uma pequena possibilidade de perda de dados

[GN⁺]

Comentários do Hacker News

• Há a opinião de que o texto é excelente, mas, do ponto de vista de quem tenta administrar banco de dados como desenvolvedor full stack, faltam casos de aplicação prática

  • Há uma pergunta sobre como verificar o quanto a réplica está atrasada em relação ao master
  • Sugere-se, como forma de monitorar a réplica, um trabalho simples de cron para verificar o estado
  • Como problema mais complexo, há uma pergunta sobre como fazer a troca para a réplica caso o servidor principal caia
  • Há uma reflexão sobre fazer a troca automaticamente ou manualmente
  • Há dúvida sobre a necessidade de duas réplicas para evitar um cenário de split brain
  • Há uma pergunta sobre como restaurar o estado original após a troca

• Afirma-se que a solução mais fácil para replicação no PostgreSQL é um operador de Kubernetes

  • CloudnativePG é citado como exemplo
  • Explica-se que não basta apenas replicação, mas também são necessários failover, recuperação, monitoramento, autorrecuperação e backup
  • Há uma pergunta sobre a existência de outras implementações gratuitas/open source além do Kubernetes

• Considera-se que um dos motivos para usar Kubernetes e Helm é poder resolver esse problema

  • Explica-se que, com o pacote PostgreSQL da Bitnami, é possível configurar tudo praticamente sem ajustes adicionais
  • Explica-se que o Postgres-ha cria um proxy para lidar profissionalmente com falhas, possibilitando failover sem interrupção

• Recomenda-se o StackGres para usuários de Kubernetes

• Por fim, há uma opinião cética de que este texto parece ter sido escrito por IA