|
FOROS PROFESIONALES
WINDEV, WEBDEV y WINDEV Mobile |
| | | | | |
| Inicio → WINDEV 25 → PostgreSQL Physical Replication:Complete Guide with Examples With WX (Windev, Webdev e WindevMobile) |
| PostgreSQL Physical Replication:Complete Guide with Examples With WX (Windev, Webdev e WindevMobile) |
| Iniciado por Boller, 23,sep. 2025 04:51 - 5 respuestas |
| |
| | | |
|
| |
Miembro registrado
4.613 mensajes |
|
| Publicado el 23,septiembre 2025 - 04:51 |
Manual
PostgreSQL Physical Replication:Complete Guide with Examples
Sumário
1. O que é replicação física
2. Quando usar replicação física
3. Terminologia e componentes principais
4. Tipos de replicação física
5. Pré-requisitos
6. Configuração passo a passo
7. Monitoramento e manutenção
8. Failover / switchover
9. Problemas comuns e soluções
10. Segurança
11. Boas práticas
⸻
1. O que é replicação física
A replicação física no PostgreSQL consiste em copiar todos os blocos de dados (nível de disco, WAL) de um servidor principal (primary ou master) para um ou mais servidores standby (standby ou replica), para que eles sejam réplicas idênticas do cluster de dados. Inclui tudo: dados, índices, etc. É oposta à replicação lógica, que opera no nível de operações (inserções, atualizações, deleções) ou por objeto (tabelas), com mais flexibilidade, porém menos “idêntica”.
Vantagens comuns:
• Alta disponibilidade: se o primary cair, promover o standby para assumir.
• Recuperação de desastres (disaster recovery).
• Possibilidade de usar réplicas para leituras (“read replicas”) ou para offloading de queries pesadas.
• Proteção de dados: menos risco de inconsistência se for bem efetuada.
Limitações:
• Réplicas são basicamente cópias do primary — não há filtragem de dados/objetos; tudo que está no primary estará na réplica.
• Menos flexível para cenários onde se quer replicar apenas parte do banco ou versões diferentes.
• Escrita só no primary; standby (em modo streaming / hot standby) pode só ler.
⸻
2. Quando usar replicação física
Alguns cenários típicos:
• Para manter cópias de segurança em servidores geograficamente distintos.
• Para garantir alta disponibilidade, com recuperação rápida em caso de falha no primary.
• Para separar workloads de leitura do de escrita, usando réplicas para queries de leitura.
• Em arquiteturas de failover automático ou manual.
• Quando se quer minimizar perda de dados (RPO baixo).
Não tão adequado:
• Quando se precisa replicar apenas parte do banco.
• Quando se precisa replicar para versões muito diferentes do PostgreSQL — replicação física requer compatibilidade de versão e binária.
• Em ambientes onde a latência de escrita for crítico e a rede entre primary e standby for instável.
⸻
3. Terminologia e componentes principais
• Primary: servidor que recebe todas as gravações (escritas).
• Standby / Replica: servidor que aplica o WAL vindo do primary; pode estar em modo somente leitura (hot standby).
• WAL (Write-Ahead Log): log de tudo que foi alterado no banco. Fundamental para replicação e recuperação.
• WAL Sender: processo no primary que envia os registros de WAL para o standby.
• WAL Receiver: no standby, recebe os WAL do primary.
• Base backup: cópia inicial dos dados do primary para iniciar o standby.
• Recovery / recovery.conf (ou parâmetros equivalentes nas versões mais recentes): configurações no standby para restaurar/seguir o primary.
• Synchronous vs Asynchronous: modos de replicação quanto à garantia de que o commit no primary aguarda confirmação do standby.
⸻
4. Tipos de replicação física
Dentro da replicação física do PostgreSQL, podemos distinguir:
• Streaming Replication: envia de forma contínua os WALs assim que disponíveis, mantendo a réplica bastante próxima do estado do primary.
• Log Shipping + arquivamento (archive-mode): os WALs são arquivados no primary e copiados/aplicados ao standby periodicamente. Pode haver atraso maior.
• Hot standby: standby configurado para aceitar conexões de leitura enquanto aplica WALs.
Também modos de replicação física síncrona ou assíncrona:
• Assíncrona: o primary não aguarda confirmação do standby para completar commits. É mais rápido, mas há risco de perda de dados se o primary cair.
• Síncrona: ao menos um standby confirma o recebimento dos WAL antes que o primary confirme o commit. Maior garantia, mas impacto de latência.
⸻
5. Pré-requisitos
Antes de iniciar:
• Versão do PostgreSQL compatível com streaming replication (geralmente versões modernas: 9.x em diante, idealmente 12, 13, 14, 15, etc.).
• Ambiente de rede estável entre primary e standby.
• Espaço de disco suficiente no primary para armazenar WALs que ainda não foram consumidos pelos standbys.
• Permissões de sistema operacional: acesso para copiar arquivos, reiniciar serviços, etc.
• Usuário com privilégios de replicação.
• Chaves SSH ou outros métodos seguros para comunicação se usar rede insegura ou internet.
⸻
6. Configuração – passo a passo
Aqui está um guia geral para configurar replicação física via streaming:
Os comandos podem variar conforme a versão do PostgreSQL; adapte-se.
6.1. Configurar o servidor primary
No postgresql.conf:
• wal_level = replica (ou hot_standby / logical dependendo da versão; para replicação física “replica” costuma bastar).
• max_wal_senders — número de conexões que irão enviar WALs para standbys.
• wal_keep_size ou wal_keep_segments — conservar WALs suficientes para manter os standbys sincronizados.
• listen_addresses — deve permitir conexões do standby.
• archive_mode = on (se quiser usar arquivamento além de streaming).
• archive_command — comando para arquivar os WALs, se aplicável.
No pg_hba.conf:
• Adicionar regra para permitir que o standby se conecte via usuário de replicação ao banco de dados postgres (ou outro definido) usando host/hostssl etc.
Criar usuário de replicação:
CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'senha_segura';
6.2. Obter base inicial do primary
No servidor standby:
• Pare o serviço do PostgreSQL (se já estiver rodando).
• Use pg_basebackup para copiar os dados do primary:
pg_basebackup -h primary_host -D /caminho/do/data_directory_standby -U replicador --wal-method=stream --checkpoint=fast
Esse comando copia todos os dados + WALs atuais necessários.
6.3. Configuração do standby
No postgresql.conf do standby:
• hot_standby = on (para permitir leituras).
• Outros ajustes de performance conforme desejar.
Arquivo de recuperação (nas versões antigas: recovery.conf; nas versões mais novas, são parâmetros no postgresql.conf ou um arquivo standby.signal):
• Configurar conexão com primary (host, usuário, senha, porta).
• Definir primary_conninfo com string de conexão.
• Se usar slots de replicação: primary_slot_name = 'nome_do_slot'.
Criar o sinal de standby (versões modernas) para ativar o standby mode: colocar arquivo standby.signal no diretório de dados.
6.4. Iniciar os servidores
• Reiniciar o primary depois de alterar sua configuração.
• Iniciar o standby; ele irá conectar, pegar a base de dados inicial, aplicar WALs e seguir o primary.
6.5. Verificar funcionamento
No primary:
SELECT * FROM pg_stat_replication;
Isso mostra replicas conectadas, quão atrasadas elas estão, etc.
No standby:
SELECT pg_is_in_recovery();
Retorna true se estiver em modo standby.
Também verificar logs para eventuais erros de conexão ou atraso.
⸻
7. Monitoramento e manutenção
Manter replicação física exige monitorar:
• Lag (atraso): quanto o standby está “atrasado” comparado ao primary. Em streaming, isso pode ser medido via LSN ou via diferenças de WAL pendente.
• Espaço em disco do primary: WALs não podem ser descartados enquanto réplicas não os consumirem; caso contrário, risco de lotar disco ou de replica ficar pendente demais.
• Número de conexões de WAL Sender vs demanda.
• Uso de CPU / I/O em standby, para garantir que o replay do WAL não cause lentidão excessiva.
• integridade dos dados: verificar que os dados foram aplicados corretamente, fazer testes de leitura.
Ferramentas úteis:
• pg_stat_replication no primary.
• pg_stat_wal_receiver no standby.
• Logs do PostgreSQL.
• Métodos de alerta (scripts, monitoramento externo).
⸻
8. Failover e switchover
• Failover: quando o primary falha, promove-se o standby a novo primary. Deve ter procedimentos definidos: como promover, redirecionar aplicações, garantir que não haja “split-brain” (dois primaries simultâneos).
• Switchover: trocar manualmente qual servidor é primary, sem perda de dados, para manutenção etc.
Passos típicos:
1. Validar que standby está sincronizado ou suficientemente atualizado.
2. Promover o standby:
# dependendo da versão
pg_ctl promote -D /caminho/do/data_directory_standby
ou criar sinal para promoção.
3. Redirecionar conexões das aplicações para o novo primary.
4. Reconfigurar antigos primaries como standby, se necessário, iniciando replicação a partir do novo primary.
⸻
9. Problemas comuns e como resolvê-los
Problema Causa típica Solução sugerida
Standby muito atrasado Alta carga no primary, rede lenta, WALs acumulados Aumentar max_wal_senders, melhorar rede, ajustar wal_keep_size ou usar archive para garantir que réplicas possam pegar WAL antigos.
WALs removidos antes que standby os consuma Sem espaço suficiente, sem configuração de retenção, ou replica offline aumentar retenção, monitorar réplicas, garantir que standby volte a se conectar, ajustar archive_mode.
Standby não aceita conexões de leitura hot_standby desligado ou configuração de autenticação incorreta ativar hot_standby; revisar postgresql.conf e pg_hba.conf.
Desempenho do primary degradado Escritas síncronas, muitos standbys, latências de rede usar replicação assíncrona se tolerável, limitar número de réplicas síncronas, otimizar configuração de rede.
Failover causa corrompimentos ou “split brain” falta de coordenação, primary ainda ativo ou replicação desalinhada ter processo de failover bem definido, usar fencing ou IP flutuante, monitorar estado antes de promoção.
⸻
10. Segurança
• Usuário de replicação com privilégios limitados; use autenticação segura (senha forte, chaves, SSL).
• Conexões criptografadas (via SSL/TLS) entre primary e standby se a rede for insegura.
• Proteção dos arquivos de backup e WAL arquivados: acesso restrito.
• Monitoramento de quem está conectando, auditoria.
⸻
11. Boas práticas
• Fazer backup regular inicial + WALs; testar restaurar a partir do backup + WALs.
• Testar failover periodicamente para garantir que tudo funciona.
• Monitorar métricas: latência, uso de recursos, espaço em disco, estado das réplicas.
• Usar versionamento compatível entre primary e standby (especialmente para físicas). Atualização coordenada.
• Limitar o número de réplicas síncronas para evitar gargalos.
• Automatizar processos de promoção/failover com ferramentas (Patroni, repmgr, etc.), se for ambiente de produção crítico.
⸻
Perfeito, Adriano 👊
Vou transformar esse manual em algo ainda mais completo, com mais detalhes técnicos, exemplos de comandos reais, comparações, diagramas de funcionamento e até dicas de automação. Assim você terá um guia de referência prática sobre replicação física no PostgreSQL.
⸻
📘 Manual Completo de Replicação Física no PostgreSQL
⸻
🔹 1. Conceito Geral
A replicação física funciona no nível de blocos e WAL (Write Ahead Log).
Cada alteração feita no primary é registrada no WAL. Esse log é enviado ao standby, que o aplica exatamente na mesma ordem, mantendo os dois bancos idênticos.
Diferença chave para replicação lógica:
• Física = byte a byte, cluster inteiro.
• Lógica = nível de instruções (DML), filtrável por tabela/coluna.
⸻
🔹 2. Arquiteturas Possíveis
A) Primary + Standby Único
[ Primary ] ---> [ Standby ]
 Primary + Múltiplos Standbys
+--> [ Standby 1 ]
[ Primary ] --+--> [ Standby 2 ]
+--> [ Standby 3 ]
C) Cascading Replication
[ Primary ] ---> [ Standby 1 ] ---> [ Standby 2 ]
D) Synchronous vs Asynchronous
• Síncrona: commit só confirma quando standby recebe/aplica WAL.
• Assíncrona: primary confirma commit sem esperar standby.
⸻
🔹 3. Pré-requisitos Técnicos
• PostgreSQL ≥ 12 (as versões modernas usam standby.signal em vez de recovery.conf).
• Rede confiável (idealmente latência < 50ms).
• Usuário dedicado à replicação com privilégio REPLICATION.
• Espaço em disco suficiente para manter WALs até que todos os standbys os recebam.
• Configuração consistente de timezone, locale e versão binária do PostgreSQL.
⸻
🔹 4. Configurações no Primary
Editar postgresql.conf:
listen_addresses = '*'
wal_level = replica
max_wal_senders = 10
wal_keep_size = 512MB
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'
Editar pg_hba.conf:
# Permitir conexões de replicação
host replication replicador 192.168.0.100/32 md5
Criar usuário:
CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'senha_super_segura';
Reiniciar PostgreSQL:
systemctl restart postgresql
⸻
🔹 5. Preparando o Standby
1. Parar o serviço PostgreSQL no standby:
systemctl stop postgresql
2. Zerar diretório de dados:
rm -rf /var/lib/postgresql/14/main/*
3. Criar cópia base usando pg_basebackup:
pg_basebackup -h 192.168.0.10 -D /var/lib/postgresql/14/main \
-U replicador -P -R --wal-method=stream
⚡ O parâmetro -R já cria o arquivo standby.signal e postgresql.auto.conf com primary_conninfo.
4. Iniciar o serviço no standby:
systemctl start postgresql
⸻
🔹 6. Verificação
No primary:
SELECT pid, client_addr, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
No standby:
SELECT pg_is_in_recovery();
-- true = está como réplica
⸻
🔹 7. Failover Manual
1. Parar o primary (simulação de falha).
2. Promover standby:
pg_ctl promote -D /var/lib/postgresql/14/main
3. Agora ele é o novo primary.
4. Reconfigurar os outros standbys para apontar para ele.
⸻
🔹 8. Automação do Failover
Ferramentas recomendadas:
• Patroni (mais usada em produção, integrada com Etcd/Consul/Zookeeper).
• repmgr (leve, apenas para replicação e failover).
• pg_auto_failover (solução oficial da comunidade).
⸻
🔹 9. Monitoramento
Queries úteis:
• No primary:
SELECT application_name, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;
• No standby:
SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(),
pg_last_xact_replay_timestamp();
Ferramentas externas:
• pg_stat_monitor
• Prometheus + Grafana
• Nagios/Zabbix plugins
⸻
🔹 10. Problemas Frequentes
Problema Sintoma Solução
Standby não conecta FATAL: no pg_hba.conf entry Revisar pg_hba.conf e firewall
Standby atrasado replay_lag alto Aumentar wal_keep_size ou usar slots de replicação
WAL sumiu antes de standby aplicar Erro de requested WAL not found Ativar archive_mode e garantir espaço em disco
Split-brain Dois primaries ativos Usar ferramenta de failover automatizado (Patroni, repmgr)
⸻
🔹 11. Segurança
• Habilitar SSL entre primary e standby:
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
• Usar senha forte ou autenticação por certificado.
• Isolar replicação em rede privada (VPN ou VLAN).
⸻
🔹 12. Boas Práticas
1. Sempre usar pg_basebackup em vez de copiar manualmente os diretórios.
2. Definir slots de replicação para evitar perda de WALs:
SELECT * FROM pg_create_physical_replication_slot('slot1');
3. Testar failover periodicamente.
4. Usar standbys para leitura pesada (reporting, BI).
5. Monitorar constantemente pg_stat_replication.
⸻
🔹 13. Exemplo de Arquitetura Completa (Produção)
+--> Standby 1 (read replica)
|
[ Primary ]----> Standby 2 (failover)
|
+--> Standby 3 (relatórios BI)
Com Patroni + etcd, failover automático acontece em segundos.
⸻
Show, 😎
Vamos turbinar ainda mais o manual, adicionando informações avançadas, exemplos práticos com código, e até cenários reais de uso em produção. Assim você terá um guia definitivo de replicação física no PostgreSQL.
⸻
🐘 Manual Avançado de Replicação Física no PostgreSQL
⸻
🔹 1. Anatomia do Processo de Replicação Física
O fluxo básico é este:
1. Primary escreve no WAL
• Cada transação gera registros no Write-Ahead Log.
2. WAL Sender envia
• Processo walsender transmite os logs ao standby.
3. WAL Receiver recebe
• Processo walreceiver grava os logs recebidos.
4. Apply (replay)
• O standby aplica os WALs na mesma ordem, garantindo consistência.
📌 Isso garante que o standby seja uma cópia byte a byte do primary.
⸻
🔹 2. Modos de Replicação (Exemplos Reais)
2.1. Replicação Assíncrona
synchronous_standby_names = ''
✅ Mais rápida, não trava o primary.
❌ Pode perder dados recentes se o primary falhar.
2.2. Replicação Síncrona
synchronous_standby_names = 'standby1'
✅ Garantia de zero perda de dados (RPO=0).
❌ Commit só confirma após standby aplicar o WAL → aumenta latência.
2.3. Replicação Quorum
synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)'
✅ Exige confirmação de 2 de 3 standbys.
✅ Balanceia performance + segurança.
⸻
🔹 3. Exemplo Completo de Configuração
3.1. Primary (postgresql.conf)
listen_addresses = '*'
wal_level = replica
max_wal_senders = 5
max_replication_slots = 5
wal_keep_size = 1024MB
archive_mode = on
archive_command = 'rsync -a %p /var/lib/postgresql/archive/%f'
3.2. Primary (pg_hba.conf)
# Permitir replicação a partir de 192.168.56.0/24
host replication replicador 192.168.56.0/24 md5
3.3. Criar usuário
CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'SenhaTop123';
3.4. Standby (pg_basebackup)
pg_basebackup -h 192.168.56.10 -D /var/lib/postgresql/14/main \
-U replicador -P -R --slot=replica1 --wal-method=stream
Isso cria automaticamente:
• standby.signal → deixa o banco em modo réplica
• postgresql.auto.conf com primary_conninfo
3.5. Standby (postgresql.auto.conf)
primary_conninfo = 'host=192.168.56.10 port=5432 user=replicador password=SenhaTop123'
primary_slot_name = 'replica1'
⸻
🔹 4. Testando e Monitorando
4.1. No Primary
SELECT application_name, state, sync_state,
write_lsn, flush_lsn, replay_lsn,
write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
🔍 Mostra status de cada standby conectado.
4.2. No Standby
SELECT pg_is_in_recovery(); -- true = em modo réplica
SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();
🔍 Mostra até onde a réplica recebeu/aplicou os WALs.
⸻
🔹 5. Exemplo de Failover Manual
1. Simular falha do primary:
systemctl stop postgresql
2. Promover o standby:
pg_ctl promote -D /var/lib/postgresql/14/main
3. Confirmar:
SELECT pg_is_in_recovery(); -- deve ser false
⸻
🔹 6. Slots de Replicação (Evita Perda de WAL)
Criar slot no primary:
SELECT * FROM pg_create_physical_replication_slot('slot_replica1');
Ver slots ativos:
SELECT * FROM pg_replication_slots;
Excluir slot:
SELECT pg_drop_replication_slot('slot_replica1');
📌 Útil para garantir que WALs não sejam apagados antes do standby consumi-los.
⸻
🔹 7. Monitoramento Avançado
7.1. Último tempo de transação aplicada no standby
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;
7.2. Lag em bytes
SELECT pg_wal_lsn_diff(pg_current_wal_lsn(),
pg_last_wal_replay_lsn()) AS bytes_lag;
⸻
🔹 8. Automação com Patroni (Exemplo)
Configuração mínima patroni.yml:
scope: postgres-cluster
name: node1
restapi:
listen: 0.0.0.0:8008
etcd:
host: 127.0.0.1:2379
postgresql:
listen: 0.0.0.0:5432
data_dir: /var/lib/postgresql/14/main
authentication:
replication:
username: replicador
password: Senha123
superuser:
username: postgres
password: SuperSenha
📌 Patroni + etcd permite failover automático em segundos.
⸻
🔹 9. Checklist de Produção
✅ Primary com wal_level=replica
✅ Usuário dedicado à replicação
✅ pg_basebackup para iniciar standbys
✅ Slots de replicação configurados
✅ Monitoramento de lag (pg_stat_replication)
✅ Backup independente da replicação (não confundir réplica com backup!)
✅ Procedimento documentado de failover e switchover
⸻
🔹 10. Arquiteturas Reais
Arquitetura Simples (HA)
Primary (Escrita) <--> Standby (Leitura + Failover)
Arquitetura Distribuída
Primary (SP) --> Standby RJ
--> Standby MG
--> Standby EUA
Arquitetura Enterprise
+--> Standby A (Reporting)
Primary --+--> Standby B (Backup)
+--> Standby C (Failover Automático com Patroni)
⸻
Perfeito! Entreguei um kit completo com scripts e exemplos prontos (Bash + SQL) para instalação, configuração, failover e monitoramento — além de amostras para automação com Patroni, repmgr e pg_auto_failover.
📦 Download do pacote
Baixar: pg_replica_kit_v1.zip
Abaixo listados os arquivos
⸻
O que vem no kit
Scripts (Bash)
• scripts/install.sh – instala PostgreSQL 15 e utilitários (Ubuntu/Debian e RHEL).
• scripts/primary-config.sh – configura o Primary (wal_level, wal_keep_size, archive_mode, pg_hba).
• scripts/standby-setup.sh – prepara o Standby com pg_basebackup, standby.signal e slot físico.
• scripts/failover.sh – promove um standby (failover manual) com pg_ctl promote.
SQL
• sql/create_slot.sql – cria e lista slots de replicação física.
• sql/monitoring.sql – consultas úteis para status, lags e métricas.
Configs & Automação
• configs/ssl-snippet.conf – trecho para ativar SSL/TLS no PostgreSQL.
• automation/patroni/patroni-node1.yml – exemplo mínimo para cluster com Patroni.
• automation/repmgr/repmgr-cheatsheet.md – passos e comandos principais do repmgr.
• automation/pg_auto_failover/pg_auto_failover-cheatsheet.md – fluxo essencial do pg_auto_failover.
README
• README.md – guia rápido de uso do pacote ponta a ponta.
⸻
Como executar (fluxo rápido)
1. Instalar PostgreSQL 15
sudo ./scripts/install.sh
2. Configurar o Primary
sudo PG_VERSION=15 ./scripts/primary-config.sh
sudo -u postgres psql -c "CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'SenhaSegura';"
sudo -u postgres psql -f sql/create_slot.sql # cria slot 'replica1'
3. Configurar o Standby
sudo PRIMARY_HOST=<IP_DO_PRIMARY> SLOT=replica1 PG_VERSION=15 ./scripts/standby-setup.sh
4. Monitorar
sudo -u postgres psql -f sql/monitoring.sql
5. Failover manual (se precisar)
sudo ./scripts/failover.sh
Observação: os scripts estão prontos para Ubuntu/Debian por padrão (caminhos /etc/postgresql/15/main e /var/lib/postgresql/15/main). Em RHEL/Rocky, ajuste DATA_DIR/CONF_DIR nos scripts ou exporte via variável.
⸻
Recomendações de automação (escolha da ferramenta)
Cenário Ferramenta Por quê
HA simples (1 primary + 1-2 standbys, time pequeno, rápida implantação) pg_auto_failover Setup muito simples, monitor próprio, failover automático sem muitas peças externas. Ótimo para começar.
Cluster distribuído (múltiplos sites, latências diversas, precisa de controle mais fino) repmgr Leve, tradicional, bom controle operacional (clone, register, promote, rejoin). Fácil de scriptar.
Missão crítica (SLO/SLAs apertados, zero-downtime planejado, governança forte) Patroni Orquestração robusta com etcd/Consul/ZooKeeper; integra pg_rewind, fencing, sincronismo/ quorum, health checks; padrão de fato em produção.
Resumo prático
• Quer subir rápido e ter failover automático? → pg_auto_failover.
• Quer controle manual/sem muito acoplamento e scripts seus? → repmgr.
• Quer o máximo de robustez e governança em missão crítica? → Patroni.
⸻
Exemplos úteis (copie e cole)
1) Ajustar replicação síncrona com quorum no Primary
# postgresql.conf
synchronous_standby_names = 'ANY 1 (standby1, standby2)'
2) Medir delay no Standby (tempo e bytes)
-- Tempo
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;
-- Bytes
SELECT pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn()) AS bytes_lag;
3) Ver status das réplicas no Primary
SELECT application_name, state, sync_state,
sent_lsn, write_lsn, flush_lsn, replay_lsn,
write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
4) Ativar SSL (trecho)
# incluir em postgresql.conf
ssl = on
ssl_cert_file = '/etc/ssl/certs/server.crt'
ssl_key_file = '/etc/ssl/private/server.key'
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.613 mensajes |
|
| Publicado el 23,septiembre 2025 - 04:51 |
# Kit de Replicação Física PostgreSQL (v1)
Este pacote contém scripts e exemplos prontos para instalar, configurar, monitorar e operar replicação física do PostgreSQL 15.
## Conteúdo
- `scripts/install.sh` — instala PostgreSQL 15 (Debian/Ubuntu ou RHEL)
- `scripts/primary-config.sh` — ajusta parâmetros do PRIMARY e pg_hba
- `scripts/standby-setup.sh` — prepara um STANDBY via pg_basebackup + slot
- `scripts/failover.sh` — promove standby (failover manual)
- `sql/monitoring.sql` — consultas úteis de monitoramento
- `sql/create_slot.sql` — cria slot físico e lista slots
- `configs/ssl-snippet.conf` — exemplo de habilitação de SSL
- `automation/patroni/patroni-node1.yml` — base do Patroni
- `automation/repmgr/repmgr-cheatsheet.md` — comandos e fluxo do repmgr
- `automation/pg_auto_failover/pg_auto_failover-cheatsheet.md` — fluxo do pg_auto_failover
## Uso rápido
1) `sudo ./scripts/install.sh`
2) No PRIMARY: `sudo ./scripts/primary-config.sh` e crie o usuário de replicação.
3) No PRIMARY (psql): `\i sql/create_slot.sql`
4) No STANDBY: `sudo PRIMARY_HOST=<ip_primary> SLOT=replica1 ./scripts/standby-setup.sh`
5) Verifique com `psql -f sql/monitoring.sql`
## Notas
- Ajuste caminhos conforme sua distro.
- Para HA automático considere **Patroni** (missão crítica), **pg_auto_failover** (simples/rápido) ou **repmgr** (leve e tradicional).
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.613 mensajes |
|
| Publicado el 23,septiembre 2025 - 04:52 |
# pg_auto_failover - Anotações Rápidas
## Conceito
Orquestra automaticamente primary/standby e failover com um "monitor" (keeper nodes + monitor node).
## Passos resumidos
1) Instalar `pg-auto-failover` (depende da distro).
2) Inicializar o "monitor" (guarda o estado do cluster).
3) Registrar o primary com o monitor.
4) Adicionar standbys; o sistema faz o clone e mantém HA.
## Comandos típicos
# Inicializar monitor:
pg_autoctl create monitor --pgdata /var/lib/postgresql/15/monitor --hostname monitor --auth trust
# Criar nó de dados (primary):
pg_autoctl create postgres --pgdata /var/lib/postgresql/15/node1 --monitor "postgres://autoctl_node@monitor/pg_auto_failover?sslmode=prefer" --auth trust
# Adicionar standby:
pg_autoctl create postgres --pgdata /var/lib/postgresql/15/node2 --monitor "postgres://autoctl_node@monitor/pg_auto_failover?sslmode=prefer" --auth trust --ssl-self-signed --disable-backup
# Ver estado:
pg_autoctl show state
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.613 mensajes |
|
| Publicado el 23,septiembre 2025 - 04:52 |
# repmgr - Anotações Rápidas
## Instalação
- Pacotes: repmgr, repmgr-common (depende da distro).
- Banco: criar DB `repmgr` e role `repmgr` com superuser.
## Config de exemplo (/etc/repmgr/15/repmgr.conf)
node_id=1
node_name=node1
conninfo='host=10.0.0.11 user=repmgr dbname=repmgr'
data_directory='/var/lib/postgresql/15/main'
use_replication_slots=yes
## Comandos úteis
# Registrar nó (primary):
repmgr -f /etc/repmgr/15/repmgr.conf primary register
# Clonar standby:
repmgr -h 10.0.0.11 -U repmgr -d repmgr -f /etc/repmgr/15/repmgr.conf standby clone
# Registrar standby:
repmgr -f /etc/repmgr/15/repmgr.conf standby register
# Failover manual:
repmgr standby promote
# Rejunção do antigo primary como standby:
repmgr node rejoin --force-rewind
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.613 mensajes |
|
| Publicado el 23,septiembre 2025 - 04:58 |
-- Cria um slot de replicação física (executar no PRIMARY)
SELECT * FROM pg_create_physical_replication_slot('replica1');
-- Ver slots
SELECT slot_name, plugin, slot_type, active, restart_lsn FROM pg_replication_slots;
-- Consultas úteis de monitoramento
-- PRIMARY: status das réplicas conectadas
SELECT pid, application_name, client_addr, state, sync_state,
sent_lsn, write_lsn, flush_lsn, replay_lsn,
write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
-- STANDBY: está em recuperação?
SELECT pg_is_in_recovery();
-- STANDBY: lag em tempo
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;
-- STANDBY: lag em bytes (aproximado)
SELECT pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn()) AS bytes_lag;
# pg_auto_failover - Anotações Rápidas
## Conceito
Orquestra automaticamente primary/standby e failover com um "monitor" (keeper nodes + monitor node).
## Passos resumidos
1) Instalar `pg-auto-failover` (depende da distro).
2) Inicializar o "monitor" (guarda o estado do cluster).
3) Registrar o primary com o monitor.
4) Adicionar standbys; o sistema faz o clone e mantém HA.
## Comandos típicos
# Inicializar monitor:
pg_autoctl create monitor --pgdata /var/lib/postgresql/15/monitor --hostname monitor --auth trust
# Criar nó de dados (primary):
pg_autoctl create postgres --pgdata /var/lib/postgresql/15/node1 --monitor "postgres://autoctl_node@monitor/pg_auto_failover?sslmode=prefer" --auth trust
# Adicionar standby:
pg_autoctl create postgres --pgdata /var/lib/postgresql/15/node2 --monitor "postgres://autoctl_node@monitor/pg_auto_failover?sslmode=prefer" --auth trust --ssl-self-signed --disable-backup
# Ver estado:
pg_autoctl show state
# repmgr - Anotações Rápidas
## Instalação
- Pacotes: repmgr, repmgr-common (depende da distro).
- Banco: criar DB `repmgr` e role `repmgr` com superuser.
## Config de exemplo (/etc/repmgr/15/repmgr.conf)
node_id=1
node_name=node1
conninfo='host=10.0.0.11 user=repmgr dbname=repmgr'
data_directory='/var/lib/postgresql/15/main'
use_replication_slots=yes
## Comandos úteis
# Registrar nó (primary):
repmgr -f /etc/repmgr/15/repmgr.conf primary register
# Clonar standby:
repmgr -h 10.0.0.11 -U repmgr -d repmgr -f /etc/repmgr/15/repmgr.conf standby clone
# Registrar standby:
repmgr -f /etc/repmgr/15/repmgr.conf standby register
# Failover manual:
repmgr standby promote
# Rejunção do antigo primary como standby:
repmgr node rejoin --force-rewind
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
4.613 mensajes |
|
| Publicado el 23,septiembre 2025 - 05:00 |
#!/usr/bin/env bash
# Promove o standby a PRIMARY (failover manual)
# Uso: sudo PG_VERSION=15 ./failover.sh
set -euo pipefail
PG_VERSION="${PG_VERSION:-15}"
DATA_DIR="${DATA_DIR:-/var/lib/postgresql/$PG_VERSION/main}"
sudo -u postgres pg_ctl -D "$DATA_DIR" promote
echo "[*] Standby promovido a PRIMARY."
#!/usr/bin/env bash
# Instalação do PostgreSQL 15 e utilitários em Ubuntu/Debian ou RHEL/CentOS/Rocky
# Uso: sudo ./install.sh
set -euo pipefail
PG_VERSION="${PG_VERSION:-15}"
if [ -f /etc/debian_version ]; then
echo "[*] Detectado Debian/Ubuntu"
apt-get update -y
apt-get install -y curl ca-certificates gnupg lsb-release
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | gpg --dearmor -o /usr/share/keyrings/postgresql.gpg
echo "deb [signed-by=/usr/share/keyrings/postgresql.gpg] http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list
apt-get update -y
apt-get install -y "postgresql-$PG_VERSION" "postgresql-client-$PG_VERSION" "postgresql-$PG_VERSION-pglogical" rsync
elif [ -f /etc/redhat-release ]; then
echo "[*] Detectado RHEL/CentOS/Rocky/Alma"
dnf -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-$(rpm -E %rhel)-x86_64/pgdg-redhat-repo-latest.noarch.rpm || true
dnf -y module disable postgresql || true
dnf -y install "postgresql$PG_VERSION-server" "postgresql$PG_VERSION" "postgresql$PG_VERSION-contrib" rsync
/usr/pgsql-$PG_VERSION/bin/postgresql-$PG_VERSION-setup initdb || true
else
echo "Sistema não suportado automaticamente."
exit 1
fi
echo "[*] Concluído. Ajuste configs em /etc/postgresql/$PG_VERSION/main (Debian) ou /var/lib/pgsql/$PG_VERSION/data (RHEL)."
#!/usr/bin/env bash
# Configura o PRIMARY para replicação física + arquivamento
# Uso: sudo PG_VERSION=15 ./primary-config.sh
set -euo pipefail
PG_VERSION="${PG_VERSION:-15}"
# Caminhos padrão (Ubuntu/Debian)
DATA_DIR="${DATA_DIR:-/var/lib/postgresql/$PG_VERSION/main}"
CONF_DIR="${CONF_DIR:-/etc/postgresql/$PG_VERSION/main}"
ARCHIVE_DIR="${ARCHIVE_DIR:-/var/lib/postgresql/wal_archive}"
LISTEN_ADDRESSES="${LISTEN_ADDRESSES:-*}"
MAX_WAL_SENDERS="${MAX_WAL_SENDERS:-10}"
WAL_KEEP_SIZE="${WAL_KEEP_SIZE:-1024MB}"
SYNC_STANDBY_NAMES="${SYNC_STANDBY_NAMES:-}" # ex: 'ANY 1 (standby1,standby2)'
mkdir -p "$ARCHIVE_DIR"
chown -R postgres:postgres "$ARCHIVE_DIR"
chmod 700 "$ARCHIVE_DIR"
PGCONF="$CONF_DIR/postgresql.conf"
HBA="$CONF_DIR/pg_hba.conf"
sed -i "s/^#\?listen_addresses.*/listen_addresses = '$LISTEN_ADDRESSES'/" "$PGCONF"
sed -i "s/^#\?wal_level.*/wal_level = replica/" "$PGCONF"
sed -i "s/^#\?max_wal_senders.*/max_wal_senders = $MAX_WAL_SENDERS/" "$PGCONF"
if grep -q '^#\?wal_keep_size' "$PGCONF"; then
sed -i "s/^#\?wal_keep_size.*/wal_keep_size = $WAL_KEEP_SIZE/" "$PGCONF"
else
echo "wal_keep_size = $WAL_KEEP_SIZE" >> "$PGCONF"
fi
if ! grep -q '^archive_mode' "$PGCONF"; then
echo "archive_mode = on" >> "$PGCONF"
else
sed -i "s/^#\?archive_mode.*/archive_mode = on/" "$PGCONF"
fi
if ! grep -q '^archive_command' "$PGCONF"; then
echo "archive_command = 'test ! -f $ARCHIVE_DIR/%f && cp %p $ARCHIVE_DIR/%f'" >> "$PGCONF"
else
sed -i "s|^#\?archive_command.*|archive_command = 'test ! -f $ARCHIVE_DIR/%f && cp %p $ARCHIVE_DIR/%f'|" "$PGCONF"
fi
if [ -n "$SYNC_STANDBY_NAMES" ]; then
if grep -q '^#\?synchronous_standby_names' "$PGCONF"; then
sed -i "s|^#\?synchronous_standby_names.*|synchronous_standby_names = '$SYNC_STANDBY_NAMES'|" "$PGCONF"
else
echo "synchronous_standby_names = '$SYNC_STANDBY_NAMES'" >> "$PGCONF"
fi
fi
# Exemplo de regra pg_hba para rede 192.168.56.0/24
if ! grep -q "host\s\+replication" "$HBA"; then
echo "host replication replicador 192.168.56.0/24 md5" >> "$HBA"
fi
systemctl restart postgresql
echo "[*] Primary configurado e reiniciado."
echo "[!] Lembre-se de criar o usuário de replicação: psql -c \"CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'SenhaSegura';\""
#!/usr/bin/env bash
# Prepara um STANDBY via pg_basebackup + slot físico
# Uso: sudo PG_VERSION=15 PRIMARY_HOST=10.0.0.10 SLOT=replica1 ./standby-setup.sh
set -euo pipefail
PG_VERSION="${PG_VERSION:-15}"
DATA_DIR="${DATA_DIR:-/var/lib/postgresql/$PG_VERSION/main}"
PRIMARY_HOST="${PRIMARY_HOST:-127.0.0.1}"
PRIMARY_PORT="${PRIMARY_PORT:-5432}"
REPL_USER="${REPL_USER:-replicador}"
REPL_PASS="${REPL_PASS:-SenhaSegura}"
SLOT="${SLOT:-replica1}"
systemctl stop postgresql || true
rm -rf "$DATA_DIR"/*
sudo -u postgres pg_basebackup -h "$PRIMARY_HOST" -p "$PRIMARY_PORT" -D "$DATA_DIR" \
-U "$REPL_USER" -R --slot="$SLOT" --wal-method=stream -P
# Ativar hot_standby (em versões atuais já é padrão ao usar -R + standby.signal)
CONF="/etc/postgresql/$PG_VERSION/main/postgresql.conf"
if ! grep -q '^hot_standby' "$CONF"; then
echo "hot_standby = on" >> "$CONF"
fi
# Adicionar primary_conninfo com password (postgresql.auto.conf já criado pelo -R)
AUTO="$DATA_DIR/postgresql.auto.conf"
if ! grep -q '^primary_conninfo' "$AUTO"; then
echo "primary_conninfo = 'host=$PRIMARY_HOST port=$PRIMARY_PORT user=$REPL_USER password=$REPL_PASS application_name=$SLOT'" >> "$AUTO"
fi
if ! grep -q '^primary_slot_name' "$AUTO"; then
echo "primary_slot_name = '$SLOT'" >> "$AUTO"
fi
systemctl start postgresql
echo "[*] Standby iniciado e seguindo $PRIMARY_HOST:$PRIMARY_PORT via slot $SLOT."
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|