O documento discute várias opções para alta disponibilidade do PostgreSQL, incluindo redundância de hardware, pooling com Pgpool e Sequoia, replicação multi-master com PgCluster e Bucardo, e replicação master-slave com Slony-I. A escolha depende dos requisitos de desempenho, sincronismo, flexibilidade e facilidade de implementação de cada projeto.

1. PostgreSQL HA
Não existe bala de prata

2. PostgreSQL HA
 Diogo Biazus
 Colaborador
 Instrutor
 Empresário

3. PostgreSQL HA
 Os três mandamentos da alta disponibilidade:
 Redundância
 Redundância
 Redundância

4. PostgreSQL HA
 Objetivos
 Aumentar o tempo entre os problemas
 Diminuir o tempo de indisponibilidade

5. PostgreSQL HA
 Como fazemos isso?
 Redundância de hardware
 Redundância de serviço de banco de dados

6. PostgreSQL HA
 Redundância de hardware
 Ótima performance
 Simples para implementar
 Pode ser pouco flexível dependendo da demanda

7. PostgreSQL HA
 Receita de redundância de hardware
 Ingredientes:
 Um storage
 Dois ou mais servidores a gosto
 Heartbeat
 Modo de preparo:
 Deixe um servidor apenas ativo
 Em caso de falha outro servidor pode assumir usando a
mesma unidade do storage

8. PostgreSQL HA
 Redundância de SGBD
 Diversas opções
 Complexidade de implementação varia de ”nem tão
simples” a ”preciso editar XMLs a mão”
 Geralmente é mais flexível que a redundância de
hardware

9. PostgreSQL HA
 Pooling
 Estratégia ”homem do
meio”
 Pgpool
 Sequoia

10. PostgreSQL HA
 Pgpool
 Feito para trabalhar com o PostgreSQL em C
 Fácil instalação e configuração
 Código bem estável
 Flexível mas precisamos de outras ferramentas
 Sequoia
 Feito para ser independente de SGBD em java
 Configuração pouco mais complexa mas bem
documentada
 Para clientes JDBC mas a solução é completa

11. PostgreSQL HA
 Problemas do pooling
 Uso de sequencias
 Sincronização de tempo
 O homem do meio é mais um cara para dar
problema

12. PostgreSQL HA
 Replicação multi-
master
 PgCluster
 Cybercluster
 Bucardo

13. PostgreSQL HA
 PgCluster / Cybercluster
 Síncrono com balanceador de carga
 Alto custo de performance
 Requer versão modificada do servidor / instável
 Suporta DDL, é bem completo
 Bucardo
 Assíncrono sem balanceador
 Não suporta chaves compostas nem DDL
 Programável via Perl
 Daemom rodando em paralelo, requer gatilhos

14. PostgreSQL HA
 Replicação master-
slave
 Slony - I

15. PostgreSQL HA
 Slony – I
 Assíncrono e sem balanceador de carga
 Daemon separado
 Usa gatilhos
 Não elege um novo master, precisa de algo como o
pool para ser funcional

16. PostgreSQL HA
 Qual escolher?
 PgCluster: Não preciso de muita performance, mas
exigo sincronismo e quero uma solução completa
(verificar estabilidade ou espírito audacioso)
 Bucardo: Não preciso de sincronismo e não tenho
chaves compostas (bom para distribuição
geográfica)

17. PostgreSQL HA
 Pgpool: Muito flexível, não quero tocar nos bancos,
não abro mão de performance.
 Sequoia: Quero uma solução completa e posso
usar JDBC
 Slony – I: Geralmente usado em conjunto com o
Pgpool, robusto e com performance. Simplifica e
melhora o failback.

18. PostgreSQL HA
Muito Obrigado
diogob@gmail.com