Escalabilidade horizontal com PostgreSQL 9.x e Pgpool II. Soluções de Software. Matheus Espanhol Novembro/2011

Transcriçã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 software complexos, com alta criticidade para os negócios Resolução de problemas tecnologicamente desafiadores e implementação de melhorias de forma prática 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: 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 /24 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' trust

17 Streaming Replication No servidor de produção, é criado o processo WalSender: postgres :39 00:00:00 postgres: writer process postgres :39 00:00:00 postgres: wal writer process postgres :39 00:00:00 postgres: stats collector process postgres :01? 00:00:00 postgres: wal sender process postgres (39593) streaming 0/ No standby, o processo WalReceiver: postgres :01 pts/0 00:00:00 /usr/local/bin/postgres postgres :01 00:00:00 postgres: startup process recovering postgres :01 00:00:00 postgres: writer process postgres :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 postgres: wal receiver process streaming 0/2000E758 postgres: startup process recovering postgres: wal receiver process streaming 0/20017BF4 postgres: startup process recovering postgres: wal receiver process streaming 0/

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 tab2; INSERT INTO tab2... SELECT * FROM tab2; SELECT * FROM tab1; COMMIT; MASTER SELECT * FROM tab1; 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 pg_current_xlog_location(); SELECT pg_last_xlog_receive_location(); /0AAF4000 0/09E8309C MASTER SLAVE delay = (0 * 16 * (1024²) * AAF4000) - (0 * 16 * (1024²) * E8309C) C70F64 em HEXA = 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) Promove um nó para master pcp_promote_node

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 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 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 São Paulo Campinas Treinamento Sistemas