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
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.