Alta Disponibilidade PostgreSQL: Arquitetura, Replicação, Failover e Continuidade
Alta Disponibilidade PostgreSQL é fundamental para empresas que precisam manter aplicações, sistemas e serviços de banco de dados operacionais mesmo diante de falhas de servidor, armazenamento, sistema operacional, rede ou outros componentes da infraestrutura. Uma arquitetura de alta disponibilidade combina redundância, replicação, servidores standby, monitoramento, mecanismos de failover, recuperação e procedimentos operacionais bem definidos.
O PostgreSQL oferece recursos que permitem construir diferentes arquiteturas de alta disponibilidade, enquanto ferramentas especializadas podem complementar o ambiente com automação de failover, gerenciamento de clusters, monitoramento e mecanismos para redirecionar as conexões das aplicações.
Em ambientes corporativos, a alta disponibilidade não deve ser tratada apenas como a existência de dois servidores PostgreSQL. É necessário projetar toda a cadeia de disponibilidade, incluindo banco de dados, replicação, rede, armazenamento, conexão das aplicações, monitoramento, backup, recuperação e Disaster Recovery.
O que é Alta Disponibilidade PostgreSQL?
Alta disponibilidade PostgreSQL é a capacidade de manter o serviço de banco de dados disponível ou recuperar sua operação rapidamente quando ocorre uma falha em um dos componentes da infraestrutura.
Uma arquitetura tradicional utiliza um servidor primário, responsável pelas operações de escrita, e um ou mais servidores standby que recebem os dados replicados. Quando ocorre uma falha no servidor primário, um standby pode ser promovido para assumir a função de novo primário.
O objetivo é reduzir o tempo de indisponibilidade e limitar o impacto de uma falha sobre as aplicações e os processos de negócio.
- Servidor primário.
- Servidores standby.
- Replicação de dados.
- Monitoramento contínuo.
- Detecção de falhas.
- Failover.
- Redirecionamento das conexões.
- Recuperação do servidor afetado.
- Backup e recuperação.
- Procedimentos operacionais documentados.
Equipe Dominus Tech analisando uma arquitetura corporativa PostgreSQL com redundância, replicação, failover automático, monitoramento contínuo, backup e Disaster Recovery.
Por que implementar Alta Disponibilidade PostgreSQL?
Um banco de dados indisponível pode interromper aplicações corporativas, sistemas financeiros, plataformas digitais, processos internos, integrações e serviços utilizados diretamente pelos clientes.
Em ambientes críticos, depender de um único servidor cria um ponto único de falha. Mesmo quando o servidor possui hardware de alta qualidade, componentes como armazenamento, sistema operacional, rede, controladoras, energia ou software podem apresentar problemas.
A alta disponibilidade introduz redundância e cria condições para que outro servidor possa assumir a operação quando o servidor principal deixar de atender corretamente.
- Redução do tempo de indisponibilidade.
- Maior resiliência da infraestrutura.
- Redução da dependência de um único servidor.
- Continuidade operacional.
- Maior capacidade de recuperação diante de falhas.
- Possibilidade de manutenção planejada.
- Integração com estratégias de Disaster Recovery.
- Maior previsibilidade dos procedimentos de recuperação.
Arquitetura PostgreSQL com Primary e Standby
Uma das arquiteturas mais utilizadas para alta disponibilidade PostgreSQL utiliza um servidor Primary e um ou mais servidores Standby.
O Primary é responsável pelas operações principais de escrita. Os servidores Standby recebem os dados replicados e mantêm uma cópia do ambiente que pode ser utilizada em estratégias de recuperação e failover.
Servidor Primary
O Primary é o servidor que normalmente recebe as operações de escrita e atende as principais conexões da aplicação.
Servidor Standby
O Standby mantém uma cópia replicada do banco de dados e permanece preparado para assumir uma função diferente caso ocorra uma falha ou uma operação planejada de switchover.
Witness
Algumas arquiteturas utilizam um nó adicional denominado Witness para auxiliar na tomada de decisão durante eventos de falha. Esse componente pode ser importante em arquiteturas nas quais é necessário reduzir o risco de decisões incorretas durante uma perda de comunicação entre os nós.
Streaming Replication no PostgreSQL
A Streaming Replication é um dos principais mecanismos utilizados em arquiteturas PostgreSQL baseadas em Primary e Standby.
O PostgreSQL utiliza o WAL, ou Write-Ahead Log, para registrar alterações realizadas no banco de dados. Esses registros podem ser transmitidos para servidores Standby, que os recebem e aplicam para manter seus dados alinhados com o servidor principal.
Replicação assíncrona
Na replicação assíncrona, o Primary não precisa aguardar que o Standby confirme a aplicação das informações antes de concluir determinadas operações.
Essa abordagem pode proporcionar excelente desempenho e menor dependência da latência entre os servidores. Entretanto, em uma falha abrupta do Primary, pode existir uma diferença entre aquilo que já foi confirmado no Primary e aquilo que chegou ao Standby.
Replicação síncrona
Na replicação síncrona, a arquitetura pode exigir confirmação de servidores de réplica antes de considerar determinadas transações concluídas.
Essa estratégia pode reduzir o risco de perda de dados em determinados cenários, mas exige planejamento cuidadoso da rede e da distância entre os servidores, pois a disponibilidade do sistema pode ficar mais dependente da comunicação entre os nós.
Replicação e objetivo de recuperação
A escolha entre replicação síncrona e assíncrona deve estar relacionada ao RPO, ao RTO, à latência disponível, à distribuição dos servidores e aos requisitos do negócio.
Alta Disponibilidade PostgreSQL e Failover
Failover é o processo pelo qual um servidor Standby assume a função de Primary depois que o servidor principal apresenta uma falha.
O PostgreSQL fornece os mecanismos necessários para manter servidores replicados, mas a automação do processo de failover normalmente envolve ferramentas de gerenciamento e orquestração.
Failover automático
No failover automático, uma ferramenta de gerenciamento detecta uma condição de falha e executa o processo de promoção de um Standby de acordo com as políticas definidas para o cluster.
Failover manual
No failover manual, um administrador avalia o incidente e decide qual servidor deve ser promovido.
Switchover
O switchover é diferente do failover porque representa uma mudança planejada da função de Primary para outro servidor. É utilizado, por exemplo, em determinadas atividades de manutenção ou mudanças controladas de infraestrutura.
EDB Failover Manager
O EDB Failover Manager é uma ferramenta destinada ao gerenciamento de clusters PostgreSQL em arquiteturas de alta disponibilidade baseadas em Primary e Standby.
O Failover Manager pode monitorar o ambiente, identificar determinadas condições de falha e promover automaticamente um servidor Standby para a função de Primary. A solução pode ser utilizada com PostgreSQL e EDB Postgres Advanced Server.
- Monitoramento dos nós.
- Detecção de falhas.
- Promoção de Standby.
- Gerenciamento do cluster.
- Utilização de Witness.
- Integração com mecanismos de conexão.
- Integração com arquiteturas utilizando VIP.
- Possibilidade de integração com componentes de pooling e proxy.
A documentação oficial da EDB descreve o Failover Manager como uma ferramenta de alta disponibilidade para arquiteturas Primary-Standby utilizando streaming replication.
Arquitetura do EDB Failover Manager
Uma arquitetura do Failover Manager pode utilizar um Primary, um ou mais Standby e um Witness.
O Primary atende as aplicações e recebe as operações de escrita. Os Standby recebem a replicação e permanecem disponíveis para recuperação. O Witness participa da avaliação da situação do cluster em determinados cenários de falha.
Primary
Servidor que normalmente atende as operações de banco de dados e recebe as escritas.
Standby
Servidor que mantém os dados replicados e pode ser promovido conforme as regras definidas para o cluster.
Witness
Componente que auxilia na avaliação da situação dos nós e na tomada de decisão durante determinados eventos de falha.
A arquitetura oficial do Failover Manager também contempla diferentes formas de encaminhar as conexões das aplicações, incluindo Virtual IP, client connection failover e integração com componentes de pooling.
Alta Disponibilidade PostgreSQL com múltiplos Standby
Ambientes corporativos podem utilizar mais de um servidor Standby para aumentar a redundância e permitir diferentes estratégias de disponibilidade e recuperação.
- Standby local para alta disponibilidade.
- Standby em outra zona de disponibilidade.
- Standby em outro site.
- Standby destinado ao Disaster Recovery.
- Standby utilizado para determinadas cargas de leitura.
- Standby adicional para aumentar a redundância.
A quantidade de servidores deve ser definida considerando requisitos de negócio, capacidade computacional, armazenamento, largura de banda, latência e complexidade operacional.
Alta Disponibilidade PostgreSQL em múltiplos Data Centers
Empresas que precisam se proteger contra falhas que afetem todo um data center podem distribuir servidores PostgreSQL entre diferentes localidades.
Essa estratégia aumenta a resiliência contra determinados eventos físicos ou operacionais, mas também acrescenta complexidade à arquitetura.
A distância entre os servidores influencia diretamente a latência da replicação e deve ser considerada especialmente quando a arquitetura possui requisitos de replicação síncrona.
O Failover Manager possui arquiteturas documentadas para ambientes que utilizam mais de um data center.
Alta Disponibilidade PostgreSQL e RPO
O Recovery Point Objective (RPO) representa a quantidade de dados que a organização aceita potencialmente perder depois de um incidente.
Em uma arquitetura de replicação assíncrona, pode existir uma diferença entre o estado do Primary e o estado do Standby no momento de uma falha.
O RPO deve ser definido antes da escolha da arquitetura, pois ele influencia a decisão sobre replicação, distribuição dos servidores e mecanismos de recuperação.
Alta Disponibilidade PostgreSQL e RTO
O Recovery Time Objective (RTO) representa o tempo máximo aceitável para recuperação do serviço.
Um failover automatizado pode reduzir o tempo necessário para promover um novo Primary, mas o RTO real envolve toda a cadeia operacional.
É necessário considerar banco de dados, mecanismo de conexão, DNS, Virtual IP, load balancer, connection pooler, aplicação e procedimentos de validação.
Alta Disponibilidade e conexão das aplicações
Ter servidores redundantes não garante, sozinho, alta disponibilidade para a aplicação.
Depois de um failover, a aplicação precisa conseguir localizar e utilizar o novo Primary.
Dependendo da arquitetura, isso pode ser realizado por:
- Virtual IP.
- DNS.
- Client connection failover.
- Connection poolers.
- Load balancers.
- Configurações específicas do driver.
O Failover Manager documenta arquiteturas utilizando Virtual IP, client connection failover, PgBouncer e EDB Pgpool-II. :
Alta Disponibilidade PostgreSQL e Connection Pooling
Connection pooling pode reduzir o custo de criação e manutenção de conexões e pode ser utilizado como parte da arquitetura de acesso ao banco de dados.
Entretanto, em um ambiente de alta disponibilidade, o pooler também precisa reconhecer a mudança do Primary após um failover.
Uma arquitetura mal configurada pode fazer aplicações continuarem tentando utilizar um servidor que deixou de ser o Primary.
O Failover Manager possui opções documentadas de integração com PgBouncer e EDB Pgpool-II para determinadas arquiteturas.
Alta Disponibilidade PostgreSQL e manutenção planejada
Alta disponibilidade também pode facilitar determinadas operações de manutenção.
Quando existe um Standby atualizado, pode ser possível executar um switchover controlado para transferir a função de Primary para outro servidor.
O procedimento deve ser planejado, testado e documentado antes de ser utilizado em produção.
Monitoramento do Cluster PostgreSQL
Um ambiente de alta disponibilidade precisa ser monitorado continuamente.
Não basta verificar se o serviço PostgreSQL está ativo. É necessário acompanhar o estado dos nós, a replicação, o atraso entre Primary e Standby e os componentes responsáveis pela continuidade do serviço.
- Estado do Primary.
- Estado dos Standby.
- Atraso de replicação.
- Estado do WAL.
- Conectividade.
- Estado dos agentes.
- Espaço em disco.
- Erros de replicação.
- Eventos de failover.
- Disponibilidade das aplicações.
- Capacidade dos servidores.
O Failover Manager possui recursos de monitoramento e gerenciamento dos nós do cluster.
Split-Brain em PostgreSQL
Um dos riscos mais importantes em arquiteturas de alta disponibilidade é o split-brain.
Esse cenário pode ocorrer quando diferentes partes da infraestrutura acreditam simultaneamente possuir autoridade para atuar como Primary.
Se dois servidores aceitarem operações de escrita simultaneamente sem uma arquitetura apropriada, podem ocorrer divergências de dados e problemas de consistência.
Por isso, mecanismos de consenso, Witness, fencing e políticas corretas de promoção são elementos importantes em determinadas arquiteturas.
Fencing e proteção contra múltiplos Primaries
Fencing é utilizado para impedir que um servidor antigo continue atendendo operações depois que outro servidor foi promovido.
O objetivo é evitar que o antigo Primary e o novo Primary funcionem simultaneamente como autoridades de escrita.
A estratégia de fencing depende da infraestrutura utilizada e pode envolver mecanismos de rede, virtualização, gerenciamento de máquinas, automação ou outros recursos.
Alta Disponibilidade PostgreSQL e Disaster Recovery
Alta disponibilidade e Disaster Recovery são conceitos relacionados, mas não representam exatamente a mesma estratégia.
Alta disponibilidade normalmente busca reduzir a indisponibilidade provocada por falhas no ambiente operacional.
Disaster Recovery busca recuperar o serviço diante de eventos mais abrangentes, como perda de infraestrutura, desastre físico ou indisponibilidade de uma localidade.
Uma arquitetura corporativa pode combinar alta disponibilidade local com um ambiente de Disaster Recovery remoto.
Alta Disponibilidade PostgreSQL e Backup
Replicação não substitui backup.
Um erro lógico, exclusão acidental ou corrupção que seja replicado também pode atingir os servidores Standby.
Por isso, uma estratégia corporativa deve combinar diferentes mecanismos de proteção:
- Alta disponibilidade.
- Replicação.
- Backups.
- Política de retenção.
- Recuperação Point-in-Time.
- Disaster Recovery.
- Testes de restauração.
Testes de Failover
Uma arquitetura de alta disponibilidade somente deve ser considerada confiável quando seus procedimentos de failover são testados regularmente.
O teste precisa avaliar não apenas a promoção do Standby, mas também a capacidade de toda a aplicação continuar funcionando.
- Simulação de queda do Primary.
- Detecção da falha.
- Promoção do Standby.
- Reconexão da aplicação.
- Validação dos dados.
- Validação do novo Primary.
- Reconfiguração dos demais Standby.
- Reintegração do servidor afetado.
- Verificação dos logs.
- Medição do tempo de recuperação.
O procedimento de criação de um cluster Failover Manager também pressupõe a existência de replicação por streaming entre Primary e Standby antes da configuração do mecanismo de alta disponibilidade.
Reintegração do antigo Primary
Depois de um failover, o servidor que anteriormente era Primary não deve simplesmente retornar à produção sem uma avaliação do seu estado.
É necessário verificar a situação do banco, a linha do tempo da replicação e o estado dos dados antes de reintegrá-lo ao cluster.
Dependendo da situação, ferramentas e procedimentos específicos do PostgreSQL podem ser utilizados para reconstruir ou sincronizar o antigo Primary como Standby.
Alta Disponibilidade PostgreSQL em ambientes corporativos
Em ambientes corporativos, alta disponibilidade deve ser tratada como uma arquitetura integrada.
O banco de dados representa apenas uma parte da cadeia de disponibilidade. Os demais componentes precisam ser projetados para acompanhar a mudança do Primary durante um incidente.
- Servidores.
- Rede.
- Armazenamento.
- Sistema operacional.
- PostgreSQL.
- Replicação.
- Failover.
- Connection pooling.
- Aplicações.
- DNS ou Virtual IP.
- Load balancers.
- Monitoramento.
- Backup.
- Disaster Recovery.
Alta Disponibilidade PostgreSQL com EDB Postgres
O ecossistema EDB oferece diferentes tecnologias que podem participar de arquiteturas corporativas baseadas em PostgreSQL.
O EDB Failover Manager é direcionado a arquiteturas Primary-Standby utilizando streaming replication, enquanto outras tecnologias do ecossistema podem atender diferentes necessidades de distribuição, replicação e disponibilidade.
A escolha da arquitetura depende do modelo de escrita, requisitos de consistência, distribuição geográfica, RPO, RTO, necessidade de escalabilidade e complexidade operacional.
PostgreSQL nativo ou EDB para Alta Disponibilidade?
O PostgreSQL oferece os recursos fundamentais necessários para construir arquiteturas robustas de alta disponibilidade, incluindo replicação e servidores Standby.
Ferramentas complementares podem automatizar monitoramento, promoção, gerenciamento do cluster e redirecionamento das conexões.
Em ambientes corporativos, uma solução como EDB Failover Manager pode simplificar determinadas arquiteturas Primary-Standby ao fornecer mecanismos específicos para gerenciamento e failover. A documentação oficial da EDB descreve o produto justamente para arquiteturas de alta disponibilidade com streaming replication.
A decisão deve considerar os requisitos técnicos e operacionais da organização, e não somente a tecnologia isoladamente.
Checklist de Alta Disponibilidade PostgreSQL
- Definir RPO.
- Definir RTO.
- Definir quantidade de Standby.
- Escolher replicação síncrona ou assíncrona.
- Definir estratégia de failover.
- Definir estratégia de switchover.
- Planejar fencing.
- Definir mecanismo de conexão da aplicação.
- Monitorar atraso de replicação.
- Monitorar os nós do cluster.
- Proteger os backups.
- Definir Disaster Recovery.
- Testar failover.
- Testar recuperação.
- Documentar procedimentos.
- Revisar periodicamente a arquitetura.
Conclusão
Alta Disponibilidade PostgreSQL é uma combinação de replicação, redundância, monitoramento, failover, conexão das aplicações, backup, recuperação e processos operacionais.
O PostgreSQL oferece os recursos fundamentais para construção dessas arquiteturas, enquanto ferramentas especializadas podem automatizar tarefas de monitoramento, promoção e gerenciamento do ambiente.
Para ambientes corporativos e de missão crítica, a arquitetura deve ser projetada de acordo com RPO, RTO, disponibilidade desejada, distribuição geográfica, requisitos de consistência e procedimentos de recuperação.
Mais importante do que simplesmente possuir servidores redundantes é garantir que o ambiente consiga detectar falhas, promover corretamente um novo Primary, redirecionar as aplicações, preservar os dados dentro do RPO definido e recuperar o nó afetado de maneira controlada.
Links Relacionados
- Replicação de dados entre servidores PostgreSQL. Replicação PostgreSQL
- Failover automático em ambientes PostgreSQL. Failover PostgreSQL
- Clusters PostgreSQL para ambientes corporativos. Cluster PostgreSQL
- Disaster Recovery para PostgreSQL. Disaster Recovery PostgreSQL
- Monitoramento de ambientes PostgreSQL. Monitoramento PostgreSQL
- Segurança para ambientes PostgreSQL. Segurança PostgreSQL
- PostgreSQL para aplicações de missão crítica. PostgreSQL para Missão Crítica
- PostgreSQL para ambientes corporativos. PostgreSQL Corporativo
- Recursos empresariais do PostgreSQL. Recursos Enterprise PostgreSQL
- EDB Failover Manager para alta disponibilidade. EDB Failover Manager
- EDB Postgres Distributed. EDB Postgres Distributed
Recursos Oficiais
- PostgreSQL — documentação oficial sobre alta disponibilidade, balanceamento e replicação. Documentação PostgreSQL — High Availability, Load Balancing and Replication
- PostgreSQL — documentação oficial sobre servidores Standby e replicação. Documentação PostgreSQL — Log-Shipping Standby Servers
- PostgreSQL — documentação oficial sobre configuração de replicação. Documentação PostgreSQL — Replication Settings
- PostgreSQL — documentação oficial sobre failover de replicação lógica. Documentação PostgreSQL — Logical Replication Failover
- EnterpriseDB — documentação oficial sobre alta disponibilidade. EDB Postgres AI — High Availability
- EnterpriseDB — documentação oficial do Failover Manager. EDB Failover Manager — Documentação Oficial
- EnterpriseDB — documentação oficial sobre arquitetura do Failover Manager. EDB Failover Manager — Architecture
- EnterpriseDB — documentação oficial para criação de um cluster Failover Manager. EDB Failover Manager — Creating a Cluster
- EnterpriseDB — documentação oficial sobre arquiteturas de implantação. EDB Failover Manager — Choosing a Deployment Architecture
- EnterpriseDB — documentação oficial sobre failover utilizando conexão do cliente. EDB Failover Manager — Client Connect Failover
- EnterpriseDB — documentação oficial sobre Failover Manager e EDB Pgpool-II. EDB Failover Manager — EDB Pgpool-II
FAQ — Perguntas Frequentes
O que é Alta Disponibilidade PostgreSQL?
É uma arquitetura que utiliza redundância, replicação, monitoramento e mecanismos de failover para reduzir o tempo de indisponibilidade do banco de dados diante de falhas.
PostgreSQL possui recursos nativos para Alta Disponibilidade?
Sim. O PostgreSQL possui recursos fundamentais para construção de arquiteturas de alta disponibilidade, incluindo replicação e servidores Standby. A automação do failover pode ser complementada por ferramentas especializadas.
Qual a diferença entre replicação e Alta Disponibilidade?
Replicação mantém dados entre diferentes servidores. Alta disponibilidade utiliza replicação juntamente com monitoramento, failover, mecanismos de conexão e procedimentos de recuperação para manter o serviço operacional.
O que é failover PostgreSQL?
É o processo de promoção de um servidor Standby para assumir a função de Primary depois de uma falha.
O que é switchover?
É uma mudança planejada da função de Primary para outro servidor, normalmente utilizada em atividades controladas de manutenção ou administração.
O PostgreSQL pode ter vários servidores Standby?
Sim. Uma arquitetura PostgreSQL pode utilizar múltiplos Standby para aumentar a redundância e atender diferentes necessidades de alta disponibilidade, recuperação e distribuição de cargas.
O EDB Failover Manager funciona com PostgreSQL?
Sim. A documentação oficial da EDB informa que o Failover Manager pode ser utilizado com PostgreSQL e EDB Postgres Advanced Server.
Alta disponibilidade substitui backup?
Não. Replicação e alta disponibilidade não substituem uma estratégia de backup. Um erro lógico ou exclusão acidental pode ser reproduzido nos servidores replicados.
Alta disponibilidade substitui Disaster Recovery?
Não necessariamente. Alta disponibilidade e Disaster Recovery possuem objetivos diferentes e podem ser utilizados conjuntamente em uma arquitetura corporativa.
É necessário testar o failover?
Sim. O failover deve ser testado periodicamente para validar a promoção do Standby, a reconexão das aplicações, a recuperação do servidor afetado e o cumprimento do RTO definido.
É possível utilizar alta disponibilidade entre diferentes Data Centers?
Sim. É possível distribuir os componentes do ambiente entre diferentes localidades, desde que a arquitetura seja dimensionada considerando latência, conectividade, replicação, consistência e requisitos de recuperação.
Modernize seu Banco de Dados com a Dominus Tech
👉Planejando uma Migração Oracle para PostgreSQL?
A Dominus Tech é Parceira Gold da EnterpriseDB e apoia empresas em todas as etapas da modernização de bancos de dados Oracle para PostgreSQL. Nossa equipe possui experiência em ambientes corporativos de missão crítica, oferecendo serviços de assessment, planejamento, migração, otimização de desempenho, alta disponibilidade, observabilidade e suporte especializado para plataformas PostgreSQL Enterprise.
✔ Parceira Gold da EnterpriseDB no Brasil
A migração de Oracle para PostgreSQL representa uma oportunidade estratégica para reduzir custos de licenciamento, modernizar a infraestrutura e construir uma plataforma preparada para o futuro. Com uma metodologia estruturada e ferramentas especializadas da EnterpriseDB, ajudamos organizações a realizar essa transição com segurança, preservando aplicações críticas e minimizando riscos operacionais.
👉Entre em contato com nossos especialistas e solicite uma avaliação técnica do seu ambiente Oracle. Descubra a melhor estratégia para migrar para PostgreSQL com segurança, desempenho e redução de custos.
