Conheça os tipos de Cluster PostgreSQL Open Source

As demandas de segurança em TI e governança de dados crescem diariamente. Por conta dos possíveis riscos à base de dados, como invasões de segurança, erros humanos ou até falhas de equipamentos, é preciso adotar as medidas mais adequadas para proteger essas informações de maneira correta e é aí que contamos com o Cluster PostgreSQL. Como medida de prevenção, os ambientes de produção atualmente devem operar com RTO – Recovery Time Objective e RPO – Recovery Point Objective próximos de zero. 

A proposta deste artigo é demonstrar as várias possibilidades de replicação para Cluster PostgreSQL, um banco de dados OpenSource, abordando as alternativas para replicações e elencando as principais vantagens e desvantagens de cada uma.

Como funciona a replicação em Cluster PostgreSQL?

A replicação no PostgreSQL é um processo de cópia de um database server para outro. Sendo assim, precisamos considerar dois diferentes bancos de dados: o Master Server, banco de dados principal de origem, e o Replica Server, servidor que recebe a replicação.

Faiolver automático no Cluster PostgreSQL:

Quando há um problema no ambiente de produção Source Database, o banco de dados é movido automaticamente para o Replica Server, e existem alguns tipos de replicação que realizam esse procedimento, e que detalharemos melhor no decorrer do artigo.

Bucardo

Trata-se de uma replicação master-master ou master-slave que tem a vantagem do load-balance para sistemas Datawarehouse, com opção de escrita em base slave, onde os dados podem ser replicados automaticamente ou por demanda.

Limitações

• Não replica DDL
• Não replica objetos grandes
• Todas as tabelas devem ter uma chave única, caso contrário, os dados não são replicados
• Há necessidade de um servidor de controle para replicação e execução de rotinas em perl, que se comunica com os outros bancos de dados: master e slave ou múltiplos master

Pgpool

Tipo de replicação de implementação ágil, por funcionar como uma extensão no Cluster PostgreSQL.

Recursos

• Possui pool de conexões
• Replicação entre um ou mais slaves
• Load Balance
• Failover automático
• Consultas paralelas

Limitações

• Se for executado um pg_terminate_backend() para finalizar uma sessão no servidor master, isso irá disparar um failover
• Consultas de várias instruções (vários comandos SQL em uma única linha) são sempre enviadas ao nó primário (no modo de replicação de streaming) ou ao nó principal (em outros modos). Normalmente, o Pgpool-II despacha a consulta para o nó apropriado, mas não é aplicado a consultas com várias instruções
• Mínimo de três servidores sendo um master e dois slaves

Repmgr

Recursos

• Monitoramento da replicação
• Servidor slave pode ser promovido sem a necessidade de reiniciar o serviço de banco de dados
• Suporte de switchover para troca de função entre primário e standby

Limitações

• Antes do PostgreSQL 10, os índices hash não eram registrados no WAL e, portanto, não são adequados para uso na replicação de streaming no PostgreSQL 9.6 e anteriores
• Após failover em caso de falha do servidor primário, este modelo, quando reestabelecido, não é iniciado como slave, portanto, esse procedimento tem de ser manual
• Mínimo de dois servidores

Patroni

Recursos

• Cria o cluster
• Inicia a replicação de streaming
• Lida com os requisitos de sincronicidade
• Monitora a vivacidade do primário e da réplica
• Pode alterar a configuração de todos os membros do cluster
• Emite comandos de recarregamento e reinicia os membros do cluster selecionados
• Lida com trocas planejadas e failovers não planejados
• Retrocede um primário com falha para colocá-lo de volta como slave 
• Reinicia todas as conexões de replicação para apontar para o primário recém-promovido
• Pode ser implementado em Kubernetes

Limitações

• Versões PostgreSQL suportadas atualmente: 9.3 a 13
• Mínimo de dois servidores para o master e slave

Um servidor para o etcd para gerenciar o Patroni