Desmistificando Replicação no PostgreSQL Euler Taveira Timbira - A empresa brasileira de PostgreSQL 09 de novembro de 2012
Apresentação Euler Taveira Desenvolvedor PostgreSQL Líder do PostgreSQL Brasil @eulerto http://eulerto.blogspot.com Timbira Diretor Técnico A empresa brasileira de PostgreSQL Consultoria Desenvolvimento Suporte 24x7 Treinamento
Sobre esta apresentação esta apresentação está disponível em: http://www.timbira.com.br/material esta apresentação está sob licença Creative Commons Atribuição-Não Comercial 3.0 Brasil: http://creativecommons.org/licenses/by-nc/3.0/br c b n
Agenda Introdução Conceitos Evolução Ferramentas Conclusão
O que é? perguntas mais frequentes curiosidades conceitos de bancos de dados como fazer
O que não é? tópicos avançados comparação com soluções de outros SGBDs soluções de replicação a nível de sistema de arquivos soluções de replicação a nível de hardware
Um pouco de teoria... Replicação significa que nós armazenamos várias cópias de uma relação ou partições dela em sites diferentes. Motivação: aumentar a disponibilidade problema na réplica falha de comunicação acelerar execução de uma consulta réplica mais próxima pode executar consulta mais rápido balancear a carga no SGBD tolerância a falhas (SPOF) Como manter a réplica quando a relação é modificada? síncrono assíncrono
Atualizando dados em um SGBD distribuído comportar-se como um SGBD centralizado para usuário problemas devem ser transparente para usuário problemas devem ser resolvidos a nível de implementação consultas: executar consultas sem se preocupar como e onde as relações estão armazenadas atualizações: transações devem continuar sendo atômicas apesar da replicação cópias da relação modificada devem ser atualizadas antes da efetivação da transação (replicação síncrona) SGBDs distribuídos comerciais adotaram replicação assíncrona independência dos dados distribuídos implementação mais eficiente do que síncrona transação que lê cópias da mesma relação pode obter registros diferentes
Replicação Síncrona custo da replicação síncrona é alto bloqueio exclusivo em todas as cópias bloqueio é mantido até que todas as cópias estejam bloqueadas uma falha de comunicação provoca uma recuperação em todas as réplicas que já haviam gravado os dados várias mensagens são trocadas até a efetivação da transação replicação síncrona é indesejável ou mesmo inalcançável em muitos cenários
Replicação Assíncrona é bastante popular mesmo que cópias diferentes da mesma relação tenham registros diferentes por um curto período de tempo viola o princípio da independência dos dados distribuídos todavia, é aceitável na grande maioria dos cenários Tipos: offline online
Métodos de Replicação offline: armazena os dados em fita (e regularmente guarda em outro local) consistência de dados é boa (a não ser por erro humano ou backup corrompido) atualidade dos dados está prejudicada tempo de recuperação não é crítico online: cópia de dados de um servidor para outro através de um link tempo de recuperação (minutos a horas) é crítico atualização dos dados em tempo real síncrono: capacidade e performance da replicação, tempo de resposta do sistema assíncrono: prejudica atualidade dos dados
Replicação Online tipos podem ser: síncrono ou assíncrono física: cada escrita no disco é replicada em outro disco no outro servidor hardware software lógica: aplicação é responsável por replicar e garantir que a escrita foi realizada em outro disco no outro servidor
Replicação Física: Hardware nó A nó B postgres off
Replicação Física: Software nó A nó B postgres off
Replicação Lógica nó A nó B
Granularidade segmento de log de transação: quando um arquivo de log de transação é arquivado, ele é aplicado no outro nó archive timeout (longo) buffer de log de transação: quando a transação é efetivada, ela é transmitida e efetivada no outro nó 1 seg (curto) Streaming Replication Warm Standby (< 9.0) segmento #1 segmento #2 aplicar em caso de desastre
Uso do servidor secundário warm standby: o servidor secundário não aceita conexões hot standby: o servidor secundário aceita conexões Hot Standby Warm Standby principal principal réplica réplica
Mais Alguns Conceitos... alta disponibilidade: manter os serviços disponibilizados o maior tempo possível balanceamento de carga: distribuir a carga de trabalho entre 2 ou mais servidores failover: processo de outro servidor assumir os serviços do servidor principal quando o último falha failback: processo de restaurar os serviços no servidor principal para o estado anterior a falha cascateamento: em replicação, servidor A replica para servidor B, servidor B replica para servidor C e D e assim sucessivamente
Evolução 8.0: warm standby 8.1: warm standby (melhorias) 9.0: replicação assíncrona e hot standby 9.1: replicação síncrona 9.2: replicação síncrona (remote write) e cascateamento?.?: replicação lógica e gatilhos de eventos
Replicação até 8.4 pg standby ( 8.3) restore command: script que espera indefinidamente arquivo WAL 1 t r i g g e r e d = f a l s e ; 2 w h i l e (! NextWALFileReady ( ) &&! t r i g g e r e d ) 3 { 4 s l e e p (100000 L ) ; / w a i t f o r 0. 1 s e c / 5 i f ( C h e c k F o r E x t e r n a l T r i g g e r ( ) ) 6 t r i g g e r e d = t r u e ; 7 } 8 i f (! t r i g g e r e d ) 9 CopyWALFileForRecovery ( ) ;
Replicação por Fluxo: Arquitetura WALReceiver estabelece uma conexão (via libpq) com servidor principal servidor principal abre o processo WalSender para enviar WAL ao servidor réplica replicação síncrona espera WAL ser escrito no disco do servidor réplica principal réplica wal buffers postgres WALSender conexão WAL postgres WALReceiver write? fsync? WAL
Replicação por Fluxo: Assíncrona replicação por fluxo no PostgreSQL é assíncrona por padrão se o servidor principal cair, algumas transações que foram efetivadas podem não ter sido replicadas a quantidade de dados perdidos é correspondente ao atraso da replicação no momento da queda
Replicação por Fluxo: Síncrona confirma que todas as mudanças feitas na transação foram transferidas para um servidor réplica cada transação que modifica dados esperará a confirmação que as mudanças foram escritas no log de transação de ambos servidores fornece um nível mais alto de durabilidade tempo da transação transferir os dados entre servidor principal e réplica escrever dados no log de transação do servidor réplica mandar mensagem do servidor réplica para principal com ACK escrever dados no log de transação do servidor principal transações somente leitura, ROLLBACK e subtransações não esperam resposta do servidor réplica
Replicação em Cascata servidor réplica aceita conexões para replicação de outros servidores réplica replicação em cascata é assíncrona não há configuração especial para habilitar a replicação em cascata promover um servidor réplica intermediário termina as conexões para replicação 9.3: não será necessário refazer as réplicas
Como funciona a replicação por fluxo? recuperação de registros do log de transação no servidor secundário entrega: arquivo ou fluxo ( stream ) no primário: processo walsender no secundário: processo walreceiver privilégio REPLICATION ( 9.1) configuração: recovery.conf e postgresql.conf monitoramento: pg current xlog location (primário) e pg last xlog {receive, replay} location (secundário)
Replicação por Fluxo: No Principal postgresql.conf listen addresses = * wal level = hot standby max wal senders = 1 wal keep segments = 100 synchronous standby names = * criar role para replicar dados CREATE ROLE usuario LOGIN REPLICATION; no pg hba.conf : host replication usuario 10.1.1.2/32 md5
Replicação por Fluxo: No Secundário recovery.conf standby mode = on primary conninfo = host=10.1.1.1 port=5432 user=usuario password=minhasenha trigger file = /bd/secundario/failover.trg postgresql.conf hot standby = on
Replicação por Fluxo: No Principal com servidor parado $ pg_ctl stop -D /bd/primario waiting for server to shut down... done server stopped $ rsync -av --exclude postgresql.conf \ --exclude pg_hba.conf --exclude pg_xlog/* \ --exclude pg_log/* /bd/primario/ \ postgres@10.1.1.2:/bd/secundario $ pg_ctl start -D /bd/primario server starting
Replicação por Fluxo: No Principal com servidor em atividade postgres=# select pg_start_backup( replicacao, true); pg_start_backup ----------------- 0/5044CB4 (1 row) $ rsync -av --exclude postmaster.pid \ --exclude postgresql.conf --exclude pg_hba.conf \ --exclude backup_label --exclude pg_xlog/* \ --exclude pg_log/* /bd/primario/ \ postgres@10.1.1.2:/bd/secundario postgres=# select pg_stop_backup(); pg_stop_backup ---------------- 0/90D7950 (1 row)
Replicação por Fluxo: No Secundário $ pg_ctl start -D /bd/secundario server starting
Algumas ferramentas... Slony-I Londiste pgpool-ii RubyRep Postgres-XC
Slony-I: Introdução sistema de replicação do principal para múltiplas réplicas suporte a cascateamento e promoção de réplica replica dados entre diferentes versões do PostgreSQL replica dados entre diferentes sistemas operacionais e modelos de servidores replica somente algumas tabelas para réplica replica diferentes conjuntos de tabelas para diferentes réplicas servidores diferentes podem ser a origem dos dados para diferentes conjuntos de tabelas
Slony-I: Ele não faz... replica objetos grandes (aka blobs) replica comandos DDL (por exemplo, CREATE TABLE, ALTER TABLE e DROP TABLE) replica alterações em roles todavia, comandos DDL podem ser submetidos as réplicas manualmente utilizando o slonik
Postgres-XC todos com mesmo timestamp transações leitura / escrita
Postgres-XC arquitetura shared nothing multi-mestre síncrono escalável em leitura/escrita 3,4x performance com 5 servidores comparado com um servidor PostgreSQL local de tabelas transparente tabelas replicadas tabelas distribuídas baseado no PostgreSQL (atualmente 9.1) mesma API para aplicações que já utilizam PostgreSQL
Postgres-XC: Arquitetura Aplicações Coordenador Catálogo Global Coordenador Catálogo Global Nó 1 Catálogo Local Nó 2 Catálogo Local GTM Proxy GTM Proxy servidor 1 servidor 2 GTM
Agenda Introdução Conceitos Evolução Ferramentas Conclusão
Outras inúmeras perguntas... A sua pergunta na lista pgbr-{geral, dev} A sua pergunta na lista pgsql-{general, performance, hackers} histórico das listas blogs http://planeta.postgresql.org.br http://planet.postgresql.org wiki http://wiki.postgresql.org
A Timbira no PGDay-SP 2012 Desmistificando Replicação no PostgreSQL (Euler Taveira) Fazendo uma manada de elefantes passar por baixo da porta (Fabio Telles)
Perguntas? Euler Taveira de Oliveira euler@timbira.com.br http://www.timbira.com.br