postgresql ha
DESCRIPTION
Palestra sobre opções para alta disponibilidade em PostgreSQLTRANSCRIPT
PostgreSQL HA
Não existe bala de prata
PostgreSQL HA
Diogo Biazus Colaborador Instrutor Empresário
PostgreSQL HA
Os três mandamentos da alta disponibilidade: Redundância Redundância Redundância
PostgreSQL HA
Objetivos Aumentar o tempo entre os problemas Diminuir o tempo de indisponibilidade
PostgreSQL HA
Como fazemos isso? Redundância de hardware Redundância de serviço de banco de dados
PostgreSQL HA
Redundância de hardware Ótima performance Simples para implementar Pode ser pouco flexível dependendo da demanda
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
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
PostgreSQL HA
Pooling Estratégia ”homem do
meio” Pgpool Sequoia
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
PostgreSQL HA
Problemas do pooling Uso de sequencias Sincronização de tempo O homem do meio é mais um cara para dar
problema
PostgreSQL HA
Replicação multi-master PgCluster Cybercluster Bucardo
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
PostgreSQL HA
Replicação master-slave Slony - I
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
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)
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.
