Replicação de banco PostgreSQL entre datacenters: streaming, logical e síncrona

Introdução à Replicação PostgreSQL entre Datacenters

A replicação de bancos de dados PostgreSQL entre datacenters não é apenas uma boa prática, mas sim uma necessidade crítica para ambientes corporativos modernos que exigem alta disponibilidade, resiliência contra desastres e continuidade de negócios. Quando falamos em replicação PostgreSQL, estamos nos referindo ao processo de manter cópias consistentes dos dados em múltiplos servidores, muitas vezes geograficamente distribuídos, para garantir que as operações não parem mesmo diante de falhas de hardware ou interrupções de rede.

Neste tutorial técnico e didático, exploraremos as três modalidades principais de replicação oferecidas pelo PostgreSQL: streaming replication, logical replication e a configuração de replicação síncrona. Cada abordagem possui um mecanismo interno distinto e atende a cenários específicos. O streaming replication opera em nível de arquivo WAL (Write-Ahead Logging), oferecendo uma réplica física quase idêntica ao primário. Já a logical replication trabalha em nível de tabela e linha, permitindo maior flexibilidade, como replicar apenas subconjuntos de dados ou integrar bancos de versões diferentes. Por fim, a replicação síncrona adiciona uma camada de garantia de consistência, assegurando que os dados estejam confirmados no primário e no(s) réplica(s) antes que a transação seja retornada ao cliente.

Configurar uma infraestrutura de alta disponibilidade PostgreSQL entre datacenters exige atenção redobrada à latência de rede, largura de banda e consistência dos dados. Erros de configuração podem levar a situações de "split-brain" (cérebro dividido) ou perda de dados em caso de failover. Portanto, este guia detalha os passos essenciais para implementar essas soluções de forma segura, incluindo configuração PostgreSQL, ajustes de rede e procedimentos de backup e recuperação PostgreSQL preliminares.

Pré-requisitos e Planejamento de Rede

Antes de tocar em qualquer arquivo de configuração, é fundamental estabelecer uma base sólida. A replicação entre datacenters introduz complexidades que não existem em ambientes locais (LAN). Abaixo, detalhamos os requisitos técnicos indispensáveis.

1. Versões Compatíveis: O PostgreSQL exige que o servidor primário e o secundário executem a mesma versão maior do software. Por exemplo, você não pode ter um primário na versão 14 e um secundário na versão 13. A compatibilidade de versões menores é geralmente suportada, mas a igualdade na versão principal é obrigatória para evitar corrupção de dados.
2. Conectividade de Rede Estável: A comunicação entre os datacenters deve ser estável e segura. O firewall e as regras de segurança devem permitir o tráfego na porta padrão do PostgreSQL, que é a 5432, tanto para conexões de replicação quanto para administração. Latências elevadas podem impactar severamente a performance da replicação síncrona.
3. Usuário de Replicação: Crie um usuário dedicado no servidor primário apenas para fins de replicação. Isso facilita a gestão de permissões e a auditoria. Exemplo: CREATE USER replica_user REPLICATION LOGIN PASSWORD 'senha_forte';
4. Autenticação Segura: Configure o arquivo pg_hba.conf para restringir o acesso apenas aos IPs dos servidores secundários. Evite usar autenticação vazia ou "trust" em ambientes de produção entre datacenters. Prefira md5 ou, idealmente, certificados SSL para criptografar o tráfego de replicação.
5. Backup Inicial: Embora a réplica física inicialize a partir do pg_basebackup, ter um backup externo validado é sua rede de segurança contra erros humanos durante a configuração. Documente o procedimento de restauração caso a réplica falhe e você precise reconstruí-la.
6. Disk I/O e Performance: A replicação gera tráfego de disco no primário (leitura de WAL) e gravação no secundário. Certifique-se de que os discos nos datacenters possuem IOPS suficientes para suportar a carga adicional sem degradar o desempenho das aplicações.

Com esses pré-requisitos validados, estamos prontos para implementar as estratégias de replicação. Vamos começar pela mais comum e eficiente em termos de recursos: o Streaming Replication.

Configuração de Streaming Replication

O streaming replication é a tecnologia nativa do PostgreSQL para criar réplicas físicas. Ela copia os registros de WAL (Write-Ahead Log) do servidor primário para os secundários em tempo real. O secundário aplica esses registros exatamente como o primário os aplicaria, resultando em uma cópia bit-a-bit dos dados. Esta é a opção recomendada para a maioria dos casos de uso de alta disponibilidade.

Passo 1: Configuração do Servidor Primário

No servidor primário, precisamos ajustar o arquivo postgresql.conf. Abra o arquivo de configuração com seu editor de texto preferido:

sudo nano /etc/postgresql/<versão>/main/postgresql.conf

Localize e modifique as seguintes diretivas. Certifique-se de remover os comentários (#) antes das linhas:

# Habilita a geração de logs WAL suficientes para replicação
wal_level = replica

# Define o número máximo de processos enviados para réplicas
max_wal_senders = 5

# Mantém arquivos WAL extras caso a réplica esteja atrasada (versões < 14)
# Em versões 14+, use wal_keep_size = '1GB'
wal_keep_segments = 64

# Permite que o PostgreSQL ouça conexões de qualquer interface
listen_addresses = '*'

Em seguida, configure o arquivo pg_hba.conf para permitir que o secundário se conecte:

# Permitir conexão de replicação do IP do secundário
host    replication     replica_user      <ip_secundário>/32    md5

Reinicie o serviço para aplicar as alterações:

sudo systemctl restart postgresql

Passo 2: Inicialização da Réplica (pg_basebackup)

No servidor secundário, pare o serviço PostgreSQL se ele estiver rodando. Em seguida, execute o comando pg_basebackup no primário para copiar os dados iniciais:

sudo -u postgres pg_basebackup -h <ip_primário> -D /var/lib/postgresql/<versão>/main -U replica_user -P -R -X stream

Este comando faz o seguinte:

• -h: Endereço do primário.
• -D: Diretório de dados do PostgreSQL no secundário.
• -U: Usuário de replicação criado anteriormente.
• -R: Gera automaticamente os arquivos standby.signal (ou recovery.conf em versões antigas) e adiciona as credenciais ao postgresql.auto.conf.
• -X stream: Inclui o envio de WALs durante a cópia, garantindo consistência.

Passo 3: Configuração do Servidor Secundário

Se o parâmetro -R foi usado, o PostgreSQL já criou o arquivo standby.signal na pasta de dados e configurou a conexão primária no postgresql.auto.conf. Verifique se o arquivo standby.signal existe:

ls /var/lib/postgresql/<versão>/main/standby.signal

Se necessário, ajuste o postgresql.auto.conf para incluir as credenciais de conexão, mas geralmente o -R cuida disso. Inicie o serviço no secundário:

sudo systemctl start postgresql

O servidor agora deve estar em modo standby, recebendo e aplicando logs do primário.

Configuração de Logical Replication

A logical replication, introduzida na versão 10 do PostgreSQL, opera de forma diferente. Em vez de copiar blocos de dados ou logs físicos, ela envia comandos DML (INSERT, UPDATE, DELETE) lógicos. Isso permite replicar apenas tabelas específicas e oferece flexibilidade para cenários complexos, como migração entre versões diferentes ou replicação bidirecional (com cuidado).

Passo 1: Configuração do Primário (Publicação)

No servidor primário, altere o postgresql.conf para habilitar o nível lógico de WAL:

wal_level = logical

Reinicie o PostgreSQL. Em seguida, crie a publicação para as tabelas desejadas:

CREATE PUBLICATION minha_publicacao FOR TABLE tabela_a, tabela_b;

Para publicar todas as tabelas, use FOR ALL TABLES. Note que tabelas sem chave primária não podem ser replicadas logicamente por padrão.

Passo 2: Configuração do Secundário (Assinatura)

No servidor secundário, crie a assinatura para conectar à publicação:

CREATE SUBSCRIPTION minha_assinatura
    CONNECTION 'host=<ip_primário> dbname=meubanco user=replica_user password=senha'
    PUBLICATION minha_publicacao;

O PostgreSQL realizará uma cópia inicial dos dados existentes e depois começará a aplicar as mudanças em tempo real. Você pode verificar o status com:

SELECT * FROM pg_stat_subscription;

A logical replication é mais leve em termos de tráfego de rede para cargas de trabalho específicas, mas pode consumir mais CPU no primário devido à necessidade de gerar logs detalhados e aplicar transações sequenciais.

Replicação Síncrona: Garantindo Consistência

A replicação síncrona não é um tipo diferente de protocolo, mas sim uma configuração de comportamento dentro do Streaming Replication. Ela garante que uma transação só seja confirmada ao cliente se os dados estiverem escritos no disco do servidor primário E nos servidores secundários designados como síncronos.

Isso elimina a possibilidade de perda de dados (zero data loss), mas aumenta a latência da aplicação, pois o tempo de resposta depende da velocidade da rede entre os datacenters.

Passo 1: Configuração do Primário

No postgresql.conf do primário, adicione ou ajuste:

# Define o método de sincronização (lista ou primeiro)
synchronous_standby_names = 'nome_do_standby1, nome_do_standby2'

O parâmetro synchronous_commit deve permanecer como on (padrão). O nome em synchronous_standby_names refere-se ao application_name configurado na réplica.

Passo 2: Configuração do Secundário

No postgresql.conf do secundário, defina o nome da aplicação:

application_name = 'nome_do_standby1'

Isso deve ser feito no arquivo postgresql.auto.conf ou na configuração de conexão usada pelo processo de replay. Em versões recentes, isso é configurado via primary_conninfo.

Passo 3: Considerações de Performance

Se um servidor síncrono ficar indisponível ou muito lento, o primário pode bloquear (hang) novas transações, esperando confirmação. Para mitigar isso, utilize o parâmetro synchronous_commit = remote_write ou configure múltiplos servidores síncronos com o modo 'first' ou 'any', permitindo que o primário continue operando se um dos secundários falhar, mas mantendo a durabilidade garantida por pelo menos um nó.

Verificação e Monitoramento

Após configurar qualquer tipo de replicação, a verificação é etapa crítica. Não assuma que está funcionando apenas porque não há erros nos logs.

1. Verificação de Streaming Replication

Conecte-se ao primário e execute:

SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn FROM pg_stat_replication;

Observe as colunas:

• state: Deve ser "streaming".
• sync_state: Se configurou síncrono, deve ser "sync" ou "potential".
• replay_lsn vs sent_lsn: Elas devem estar muito próximas. Se houver grande diferença, a réplica está atrasada (lag).

2. Verificação de Logical Replication

No secundário, verifique o status da assinatura:

SELECT subname, pid, received_lsn, last_msg_send_time, last_msg_receipt_time, latest_end_lsn, latest_end_time FROM pg_stat_subscription;

O substate deve ser "ready" ou "streaming". Se estiver "initializing", o carregamento inicial ainda está em andamento.

3. Teste de Escrita

A forma mais segura de verificar é inserir um registro no primário e confirmar que ele aparece no secundário em segundos. Para logical replication, verifique se a estrutura da tabela existe no secundário antes de inserir dados.

Troubleshooting Comum

Problemas na replicação entre datacenters são frequentes devido à natureza da rede. Aqui estão soluções para erros comuns:

• Erro de Conexão (FATAL: no pg_hba.conf entry): Verifique se o IP do servidor secundário está listado no pg_hba.conf do primário e se o serviço foi reiniciado após a alteração.
• Lag Crescente: Se a réplica não consegue acompanhar o primário, verifique a largura de banda da rede entre os datacenters. Aumente o wal_keep_size no primário para evitar que logs antigos sejam apagados antes de serem aplicados. No secundário, verifique se o disco está saturado.
• Split-Brain: Nunca inicie o servidor secundário em modo "primário" sem antes desativar a replicação no primário. Use um arquivo de trigger (como /tmp/trigger_file) para promover a réplica com segurança: touch /tmp/trigger_file.
• Diferença de Versão: Se você estiver usando logical replication, verifique se o esquema da tabela no secundário é compatível. O PostgreSQL não permite replicação se houver colunas faltando ou tipos incompatíveis.

Aviso Importante: A replicação síncrona pode causar travamentos na aplicação se a rede entre datacenters falhar. Teste sempre em ambiente de homologação como o primário se comporta quando um standby síncrono cai. Considere usar replicação assíncrona para standby geográficos distantes e síncrona apenas para failover local ou regional de alta latência tolerante.

Perguntas Frequentes (FAQ)

Posso usar replicação PostgreSQL entre datacenters com alta latência?

Sim, mas a escolha do método é crucial. O streaming replication assíncrono funciona bem com latências moderadas. A replicação síncrona é altamente recomendada contra ambientes com latência muito alta (acima de 50-100ms), pois cada gravação esperará pela resposta do secundário, tornando a aplicação inutilmente lenta. Para datacenters muito distantes, considere replicação assíncrona ou soluções de armazenamento replicado em nível de bloco.

Qual a diferença prática entre Streaming e Logical Replication?

O Streaming cria uma cópia física exata. Você não pode ler dados no secundário enquanto ele está em standby (a menos que use hot-standby, mas ainda assim é apenas leitura). A Logical Replication permite que o secundário tenha tabelas específicas e até outras tabelas não replicadas, além de ser possível fazer leituras e escritas locais simultaneamente (em cenários de multi-master, com cuidado). O streaming é mais eficiente para backups e failover completo; o logical é melhor para migração e arquitetura distribuída.

O que acontece se a rede cair durante a replicação síncrona?

O servidor primário continuará aceitando transações, mas elas serão marcadas como "pendentes" de confirmação. Se a conexão com o standby síncrono for perdida e não houver outros standbys síncronos configurados (ou se o modo for 'any' e apenas um estiver disponível), o primário pode entrar em estado de espera ou falhar, dependendo da configuração synchronous_standby_names. É vital ter um plano de contingência.

Como faço backup do servidor secundário?

Não realize backups diretos no servidor secundário em modo standby, pois isso pode interromper o processo de replay. Pare o serviço PostgreSQL no secundário, faça o backup dos arquivos de dados e reinicie o serviço. Para backups online sem parar o serviço, use pg_basebackup ou ferramentas como Barman/Postgres Backups, que interagem com o servidor primário ou usam snapshots de disco compatíveis.

A replicação lógica suporta chaves estrangeiras?

Não nativamente da forma tradicional. A logical replication não replica a restrição de chave estrangeira (FK) por padrão, pois isso poderia causar problemas de integridade se as linhas referenciadas ainda não tivessem sido replicadas no secundário. Você deve criar as restrições FK manualmente no secundário após o carregamento inicial dos dados.

Conclusão

A implementação de replicação PostgreSQL entre datacenters é um pilar fundamental para a robustez da sua infraestrutura de TI. Ao dominar as nuances do streaming replication, da logical replication e da configuração de replicação síncrona, você garante que seus dados estejam seguros, disponíveis e consistentes, independentemente de falhas locais.

Lembre-se de que a tecnologia é apenas parte da solução. A monitorização contínua, os testes regulares de failover e o dimensionamento adequado da rede entre os datacenters são igualmente importantes para o sucesso da sua estratégia de alta disponibilidade PostgreSQL. Não espere uma falha real para descobrir que sua configuração de backup e recuperação PostgreSQL não está adequada.

A Toda Solução entende as complexidades de manter infraestruturas críticas. Oferecemos soluções de hospedagem, VPS e infraestrutura cloud otimizadas para bancos de dados de alto desempenho, com suporte especializado para garantir que sua replicação funcione perfeitamente. Confie em parceiros que entendem a profundidade técnica necessária para manter seus negócios online.