O documento discute como o PostgreSQL 9.x e o Pgpool II podem ser usados juntos para fornecer escalabilidade horizontal e alta disponibilidade. O Pgpool II oferece balanceamento de carga, replicação síncrona e failover automático entre servidores PostgreSQL. Isso permite aumentar a capacidade de processamento adicionando novos servidores de forma transparente à aplicação.

1. Escalabilidade horizontal com
PostgreSQL 9.x e Pgpool II
Matheus Espanhol
Novembro/2011
Soluções de Software
Sistemas e aplicações sob medida para as
necessidades do seu negócio.

2. Agenda
Histórico
PostgreSQL 9.x Streaming Replication/Hot Standby
Pgpool-II
Pool de conexões
Balanceamento de carga
Pgpool-II 3.x + PostgreSQL 9.x
Escalabilidade
Monitoramento
Failover automático
PgpoolHA e Pgpooladmin

3. A Dextra

4. Soluções de Software
Projeto e Sustentação de Resolução de problemas tecnologicamente
software complexos, com desafiadores e implementação de
alta criticidade para melhorias de forma prática
os negócios
Transferência de conhecimento
e aprimoramento de competências

5. Clientes

6. Dextra e PostgreSQL
A Dextra oferece serviços no banco de dados PostgreSQL desde
1999
Gerência de Serviços PostgreSQL, focada na garantia de qualidade
dos serviços oferecidos
Projetos de grande porte com empresas e governo
Equipe especializada de DBAs PostgreSQL

7. Consultoria
Resolução efetiva de problemas desafiadores e complexos
Os serviços oferecidos englobam:
Instalação e configuração de servidores PostgreSQL para aplicações
críticas
Migração de sistemas de outros bancos de dados (Oracle, SQL
Server, Informix, MySQL entre outros) para PostgreSQL
Modelagem de banco de dados
Administração preventiva
Soluções de monitoramento
Ajustes de performance
Replicação de bancos de dados
Soluções de alta disponibilidade e desempenho
Desenvolvimento de aplicações com PostgreSQL

8. Suporte Técnico
Segurança na implantação e administração de ambientes críticos
Gestão voltada à garantia da qualidade dos serviços
Acordos de Nível de Serviço (SLA)
Aumento do nível de satisfação dos usuários
Gerenciamento de ambientes PostgreSQL
Monitoramento eficiente do banco de dados
Administração preventiva
Transferência de conhecimento
Modelo flexível: 24 x 7 ou 8 x 5

9. Casos de Sucesso – Consultoria e Suporte

10. Capacitação
Transferência de conhecimento e aprimoramento de competências
Treinamentos com profissionais que vivenciam o dia-a-dia do
desenvolvimento de software e das rotinas do banco de dados PostgreSQL
Turmas abertas ou In-Company
Customização de conteúdos
Mais de 15 mil alunos treinados
PostgreSQL Essencial
Linguagem Procedural PL/pgSQL
Administração (DBA)
Performance Tuning
PostgreSQL Alta Disponibilidade
PostGIS
PostgreSQL para BI e Datawarehouse

11. Casos de Sucesso – Treinamento

12. Histórico
2003 – Início do desenvolvimento do Pgpool
Apenas middleware para pool de conexões
2004 – Replicação e balanceamento de carga implementados
2006 – Criado o Pgpool Global Development Group
2006 – Pgpool II 1.0, Pgpool-HA e Pgpooladmin liberados
2007 – Pgpool 3.4 e Pgpool II 2.0 liberados
2010 – PostgreSQL 9.0 liberado
2010 – Pgpool II 3.0 e PgpoolAdmin 3.0 liberados
2011 – PostgreSQL 9.1 liberado
2011 – Pgpool II 3.1 liberado

13. PostgreSQL 9.x
Transferência por fluxo (fragmentos) de logs de transação.
Servidor slave em modo read-only
Failover através da criação de arquivo gatilho

14. Hot Standby
Servidor standby disponível em modo read-only:
postgres@dextra02:~$ psql pagila
pagila=# UPDATE actor SET last_update = now();
ERROR: cannot execute UPDATE in a read-only transaction
Restauração ocorre paralelamente às consultas
Em caso de failover:
Conexões ativas são mantidas e autorizadas a alterar a base de
dados sem a necessidade de reconexão

15. Streaming Replication
Criação de um canal de comunicação via TCP/IP
Replicação por fluxo entre os servidores master e slaves
Transferência de fragmentos de segmentos de log de transação
Criação de processos WalSender e WalReceiver, iniciados nos
servidores master e slaves respectivamente
File-based Replication Record-based Replication

16. Streaming Replication + Hot Standby
postgresql.conf no servidor master:
wal_level = hot_standby
max_wal_senders = 10
wal_keep_segments = 100
pg_hba.conf no servidor master:
host replication all 192.168.40.0/24 trust
postgresql.conf no servidor slave:
hot_standby = on
recovery.conf no servidor slave ($PGDATA):
standby_mode = 'true'
primary_conninfo = 'host=dextra01'
trigger_file = '/tmp/arquivo_gatilho.pgsql'

17. Streaming Replication
No servidor de produção, é criado o processo WalSender:
postgres 2568 2566 08:39 00:00:00 postgres: writer process
postgres 2569 2566 08:39 00:00:00 postgres: wal writer process
postgres 2572 2566 08:39 00:00:00 postgres: stats collector process
postgres 3071 2566 0 09:01 ? 00:00:00 postgres: wal sender process
postgres 192.168.40.128(39593) streaming 0/19000000
No standby, o processo WalReceiver:
postgres 4295 1 09:01 pts/0 00:00:00 /usr/local/bin/postgres
postgres 4296 4295 09:01 00:00:00 postgres: startup process recovering
000000010000000000000020
postgres 4298 4295 09:01 00:00:00 postgres: writer process
postgres 4565 4295 09:09 00:00:00 postgres: wal receiver process
streaming 0/2000E758

18. Streaming Replication
As alterações que ocorrem no servidor de produção são enviadas
continuamente para os servidores standby.
A cada atualização, o stream do arquivo de log é incrementado:
postgres: startup process recovering 000000010000000000000020
postgres: wal receiver process streaming 0/2000E758
postgres: startup process recovering 000000010000000000000020
postgres: wal receiver process streaming 0/20017BF4
postgres: startup process recovering 000000010000000000000020
postgres: wal receiver process streaming 0/20026684

19. Pgpool II features
Pool de conexões
Balanceamento de carga
Replicação síncrona dual-master
Modo master/slave
Suporte para online recovery
Failover automático
Consultas paralelas

20. Pool de conexões
“Aglomeração” de conexões mantidas com o PostgreSQL
Conexão de forma transparente
Para a aplicação, o Pgpool é o próprio PostgreSQL;
Para o PostgreSQL o Pgpool é um cliente comum.
Não há necessidade de alterações na aplicação
Redução do overhead causado pelo fork de processos
Controle do número de conexões e tamanho do pool
Caso as requisições ultrapassem o tamanho do pool, uma fila de
requisições é criada

21. Pool de conexões

22. Pool de conexões

23. Pool de conexões: Configuração
num_init_children
Número de processos filhos do Pgpool II iniciados juntamente
com o servidor
max_pool
Número máximo de conexões mantidas em cache para cada
processo filho do Pgpool II
O cache é utilizado quando há diferentes combinações entre
banco/usuário na string de conexão
max_connections >= (num_init_children * max_pool)

24. Balanceamento de carga
Consultas são enviadas aleatoriamente entre os servidores
PostgreSQL
A prioridade (peso) dos servidores pode ser alterada
O parser do Pgpool II possibilita o tratamento diferenciado para as
operações SQL
O modo master/slave do Pgpool II prevê a distinção dos comandos
inválidos no servidor read-only
Condições para o balanceamento:
Não ser transação explícita (BEGIN; … COMMIT;)
Não atualizar sequences (SELECT nextval e setval)
Não ser SELECT INTO, SELECT FOR UPDATE ou FOR SHARE
Iniciar com SELECT, COPY TO, DECLARE, FETCH, CLOSE ou EXPLAIN

25. Balanceamento de carga

26. Balanceamento de carga
PGPOOL
BEGIN;
SELECT * FROM tab1;
SELECT * FROM tab2;
INSERT INTO tab2...
SELECT * FROM tab2;
SELECT * FROM tab1;
COMMIT;
MASTER SLAVE

27. Balanceamento de carga: pgpool.conf

28. Balanceamento de carga: Workaround
black_function_list:
Lista de funções que executam alterações na base
white_function_list:
Lista de funções que não executam alterações na base
Não utilizar ambas as listas
Alternativa:
/*NO LOAD BALANCE*/ SELECT ...
/*LOAD BALANCE*/ SELECT...
Não utilizar transações explícitas sem necessidade

29. Pgpool II 3.0 features
Modo master/slave específico para Streaming Replication
Balanceamento de consultas em transações explícitas
Verificação do atraso dos slaves com relação ao master
Não envia consultas para servidores que ultrapassem o limite de
atraso estabelecido no parâmetro delay_threshold
Permite o uso de tabelas temporárias
Permite o uso do online recovery para Streaming Replication
Log de status dos servidores slaves
Suporte a autenticação md5

30. Pgpool II 3.1 features
Permite a utilização de cursores de drivers JDBC nos slaves
Correção do problema com locks em sequences
Função pcp_attach_node adiciona servidores sem reinício de
conexões
Importação do parser do PostgreSQL 9
Maior segurança para evitar failover e failback desnecessários
Permite expressão regular para especificar funções em
black_function_list e white_function_list

31. Pgpool II 3.x: Arquitetura

32. Pgpool II 3.x + PostgreSQL 9.x

33. Pgpool II 3.x + PostgreSQL 9.x
Menor impacto nas operações de escrita
Diferença mínima entre os servidores master e slaves
Aumento da performance com Pool de Conexões e Balanceamento
de Carga
Failover automático dos nós
Replicação completa de todos os bancos, BLOBs e DDL
Garantia de consultas balanceadas somente entre slaves
atualizados com o master (delay_threshold)
Administração online do cluster
Eliminação de Ponto Único de Falha (SPOF) através da redundância
do servidor Pgpool II

34. Escalabilidade

35. Escalabilidade – Resultados Obtidos com DBT2
24%
70%

36. Monitoramento >= 3.1
Processo dedicado a verificação de atraso da replicação e
determinar o nó master
sr_check_period : Intervalo entre as verificações da replicação
SELECT pg_current_xlog_location()
SELECT pg_last_xlog_replay_location()
sr_check_user : Usuário para conexão com o banco de dados
sr_check_password : Senha do usuário

37. Monitoramento
PGPOOL
SELECT SELECT
pg_current_xlog_location(); pg_last_xlog_receive_location();
------------------------ ------------------------
0/0AAF4000 0/09E8309C
MASTER SLAVE
delay = (0 * 16 * (1024²) * 255 + 0AAF4000) - (0 * 16 * (1024²) * 255 + 09E8309C)
C70F64 em HEXA = 13045604 bytes
delay_threshold
Valor de tolerância ao atraso entre master e slaves (em bytes)

38. Monitoramento
log_per_node_statement
log_standby_delay
always : Grava no log todos os resultados de verificação do atraso
if_over_threshold : Grava no log somente quando atraso exceder o valor de
delay_threshold
none : Desabilita a gravação do atraso no log

39. Failover automático

40. Failover automático
Processo que verifica o estado dos nós em cada servidor
health_check_timeout = 10
health_check_period = 20
health_check_user = 'postgres'
health_check_password = ''
Definição de comando para failover e failback:
failover_command : Executado quando o servidor PostgreSQL
para de responder (pcp_detach_node)
follow_master_command : Executado logo após a definição do
novo master
failback_command : Executado quando é adicionado um novo nó
no balanceamento (pcp_attach_node)

41. Failover automático
Failover
Failback

42. Gerenciamento remoto do cluster
Comandos PCP
pcp_node_count Número de nós envolvidos
pcp_node_info Informações sobre cada nó
pcp_proc_count Lista de processos iniciados
pcp_proc_info Informações sobre cada processo
pcp_detach_node Retira um nó do balanceamento
pcp_attach_node Adiciona um nó ao balanceamento
pcp_stop_pgpool Para o processo do Pgpool II
pcp_recovery_node Dispara um script de recuperação do
servidor PostgreSQL (backup base)
pcp_promote_node Promove um nó para master

43. Gerenciamento remoto do cluster
SHOW pool_status;
Informações sobre a configuração atual
SHOW pool_nodes;
Informações sobre o status dos nós declarados
SHOW pool_processes;
Informações sobre processos do Pgpool II
SHOW pool_pools;
Todos os pools de conexão (utilizados ou não)
SHOW pool_version;
Versão do Pgpool II instalada

44. Cuidados necessários
Após o failover o Pgpool II passa a enviar imediatamente alterações
para o novo servidor master
O PostgreSQL pode levar um tempo para transformar o servidor
slave em master
Workaround: Fazer a verificação através do próprio script
failover.sh?
Este problema é conhecido e deve ser corrigido nas próximas
versões
Na medida do possível, evite o failover automático
O PostgreSQL pode ficar inacessível para o Pgpool II por vários
motivos
O Pgpool II pode executar um failover equivocadamente

45. PgpoolHA
Agente do Heartbeat para garantir a disponibilidade do servidor
Pgpool II
Elimina o Ponto Único de Falha através da redundância do
middleware Pgpool II
Um novo servidor Pgpool II deve estar pré-configurado para assumir
automaticamente quando necessário

46. PgpoolAdmin 3.1.0
Ferramenta web de administração do Pgpool II
Principais funcionalidades
Gerenciamento do processo servidor Pgpool II
Monitora os nós e processos
Switchover de servidores PosgreSQL
Edição dos arquivos de configuração pgpool.conf e pcp.conf

47. PgpoolAdmin 3.1.0
Visualização do pool de conexões

48. O que vem por aí...
PostgreSQL 9.2
Replicação em cascata
Dados diretamente de índices
Backup base online a partir de
servidor slave

49. Conclusão
Escalabilidade horizontal simples e confiável
Alta disponibilidade garantida
Configuração e administração simples
Não envolve alterações na aplicação
Uma excelente solução para a maioria das aplicações
Comunidade ativa na correção de bugs e desenvolvimento de
melhorias
Solução completamente livre

50. Perguntas...

51. Fale conosco
Matheus Ricardo Espanhol
matheus.espanhol@dextra.com.br
www.dextra.com.br
São Paulo 11 3051.7711
Campinas 19 3256.6722
Treinamento www.facebook.com.br/dextratreinamentos Treinamento @dextracursos
Sistemas www.facebook.com.br/dextrasis Sistemas @dextrasistemas