escalabilidade horizontal com postgresql e pgpool ii

Soluções de Software

Sistemas e aplicações sob medida para asnecessidades do seu negócio.

Escalabilidade horizontal comPostgreSQL 9.x e Pgpool II

Matheus EspanholNovembro/2011

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

A Dextra

Soluções de Software

Transferência de conhecimentoe aprimoramento de competências

Resolução de problemas tecnologicamente desafiadores e implementação de

melhorias de forma prática

Projeto e Sustentação de software complexos, com alta criticidade paraos negócios

Clientes

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

Dextra e PostgreSQL

ConsultoriaResoluçã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

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

Casos de Sucesso – Consultoria e Suporte

CapacitaçãoTransferê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

Casos de Sucesso – Treinamento

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

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

Hot Standby

Servidor standby disponível em modo read-only:postgres@dextra02:~$ psql pagilapagila=# 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

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

Streaming Replication + Hot Standby

postgresql.conf no servidor master:wal_level = hot_standbymax_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'


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


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 000000010000000000000020postgres: wal receiver process streaming 0/2000E758

postgres: startup process recovering 000000010000000000000020postgres: wal receiver process streaming 0/20017BF4

postgres: startup process recovering 000000010000000000000020postgres: wal receiver process streaming 0/20026684

Pgpool II features

Pool de conexões


Replicação síncrona dual-master

Modo master/slave

Suporte para online recovery


Consultas paralelas

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

Pool de conexões

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)max_connections >= (num_init_children * max_pool)


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 SHAREIniciar com SELECT, COPY TO, DECLARE, FETCH, CLOSE ou EXPLAIN


BEGIN;

SELECT * FROM tab2;INSERT INTO tab2...SELECT * FROM tab2;SELECT * FROM tab1;COMMIT;

SELECT * FROM tab1;

MASTER SLAVE

PGPOOL

Balanceamento de carga: pgpool.conf

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

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

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

Pgpool II 3.x: Arquitetura

Pgpool II 3.x + PostgreSQL 9.x

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

Escalabilidade

Escalabilidade – Resultados Obtidos com DBT2

70%

24%

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çãoSELECT 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

Monitoramento >= 3.1

Monitoramento

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)

SELECT pg_current_xlog_location();------------------------ 0/0AAF40000/0AAF4000

PGPOOL

MASTER SLAVE

SELECT pg_last_xlog_receive_location();------------------------ 0/09E8309C0/09E8309C

Monitoramento

log_per_node_statement

log_standby_delay

always : Grava no log todos os resultados de verificação do atrasoif_over_threshold : Grava no log somente quando atraso exceder o valor de delay_thresholdnone : Desabilita a gravação do atraso no log

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)



Failover

Failback

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

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

Gerenciamento remoto do cluster

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

Cuidados necessários

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

PgpoolAdmin 3.1.0

Ferramenta web de administração do Pgpool II

Principais funcionalidades

Gerenciamento do processo servidor Pgpool IIMonitora os nós e processosSwitchover de servidores PosgreSQLEdição dos arquivos de configuração pgpool.conf e pcp.conf

PgpoolAdmin 3.1.0

Visualização do pool de conexões

O que vem por aí...

PostgreSQL 9.2

Replicação em cascata

Dados diretamente de índices

Backup base online a partir de servidor slave

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

Conclusão

Perguntas...

Fale conosco

Matheus Ricardo [email protected]

www.dextra.com.brSão Paulo 11 3051.7711Campinas 19 3256.6722

Treinamento www.facebook.com.br/dextratreinamentos

Sistemas www.facebook.com.br/dextrasis

Treinamento @dextracursos

Sistemas @dextrasistemas

mailto:[email protected]

escalabilidade horizontal com postgresql e pgpool ii

Technology