pcsoft.br.windevCopyright 2026, PC SOFT23 Sep 2025 05:00:27 Z23 Sep 2025 04:51:13 ZManual 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 ] B) 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/30WEBDEVpt_BRhttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev/read.awpmoderateur@pcsoft.fr (O moderador)webmaster@pcsoft.fr (O webmaster)Bollerpcsoft.br.windevhttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5326/read.awp23 Sep 2025 05:00:27 Z#!/usr/bin/env bash # Promove o standby a PRIMARY (failover manual) # Uso: sudo PG_VERSION=15 ./failover.sh set -euo pipefail…https://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5326/read.awphttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5326/read.awpPostgreSQL Physical Replication:Complete Guide with Examples With WX (Windev, Webdev e WindevMobile)Bollerpcsoft.br.windevhttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5325/read.awp23 Sep 2025 04:58:46 Z-- Cria um slot de replicação física (executar no PRIMARY) SELECT * FROM pg_create_physical_replication_slot('replica1'); -- V…https://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5325/read.awphttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5325/read.awpPostgreSQL Physical Replication:Complete Guide with Examples With WX (Windev, Webdev e WindevMobile)Bollerpcsoft.br.windevhttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5324/read.awp23 Sep 2025 04:52:48 Z# repmgr - Anotações Rápidas ## Instalação - Pacotes: repmgr, repmgr-common (depende da distro). - Banco: criar DB `repmgr`…https://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5324/read.awphttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5324/read.awpPostgreSQL Physical Replication:Complete Guide with Examples With WX (Windev, Webdev e WindevMobile)Bollerpcsoft.br.windevhttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5323/read.awp23 Sep 2025 04:52:21 Z# pg_auto_failover - Anotações Rápidas ## Conceito Orquestra automaticamente primary/standby e failover com um "monitor" (ke…https://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5323/read.awphttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5323/read.awpPostgreSQL Physical Replication:Complete Guide with Examples With WX (Windev, Webdev e WindevMobile)Bollerpcsoft.br.windevhttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5322/read.awp23 Sep 2025 04:51:41 Z# Kit de Replicação Física PostgreSQL (v1) Este pacote contém scripts e exemplos prontos para instalar, configurar, monitorar…https://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5322/read.awphttps://forum.pcsoft.fr/pt-BR/pcsoft.br.windev/5321-postgresql-physical-replicationcomplete-guide-with-examples-with-windev-5322/read.awpPostgreSQL Physical Replication:Complete Guide with Examples With WX (Windev, Webdev e WindevMobile)