Desmistificando Replicação no PostgreSQL
Euler Taveira
Timbira - A empresa brasileira de PostgreSQL
09 de novembro de 2012
Apresentação
I
Euler Taveira
I
I
I
I
I
Desenvolvedor PostgreSQL
Lı́der do PostgreSQL Brasil
@eulerto
http://eulerto.blogspot.com
Timbira
I
I
I
I
I
I
Diretor Técnico
A empresa brasileira de PostgreSQL
Consultoria
Desenvolvimento
Suporte 24x7
Treinamento
Sobre esta apresentação
I
esta apresentação está disponı́vel em:
http://www.timbira.com.br/material
I
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 é?
I
perguntas mais frequentes
I
curiosidades
I
conceitos de bancos de dados
I
como fazer
O que não é?
I
tópicos avançados
I
comparação com soluções de outros SGBDs
I
soluções de replicação a nı́vel de sistema de arquivos
I
soluções de replicação a nı́vel de hardware
Um pouco de teoria...
I
I
”Replicação significa que nós armazenamos várias cópias de
uma relação ou partições dela em sites diferentes.”
Motivação:
I
aumentar a disponibilidade
I
I
I
acelerar execução de uma consulta
I
I
I
I
problema na réplica
falha de comunicação
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?
I
I
sı́ncrono
assı́ncrono
Atualizando dados em um SGBD distribuı́do
I
comportar-se como um SGBD centralizado para usuário
I
problemas devem ser transparente para usuário
I
problemas devem ser resolvidos a nı́vel de implementação
consultas:
I
I
I
executar consultas sem se preocupar como e onde as relações
estão armazenadas
atualizações:
I
I
I
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
I
I
I
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
I
custo da replicação sı́ncrona é alto
I
I
I
I
I
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
I
é bastante popular mesmo que cópias diferentes da mesma
relação tenham registros diferentes por um curto perı́odo de
tempo
I
viola o princı́pio da independência dos dados distribuı́dos
I
todavia, é aceitável na grande maioria dos cenários
Tipos:
I
I
I
offline
online
Métodos de Replicação
I
offline: armazena os dados em fita (e regularmente guarda
em outro local)
I
I
I
I
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
I
I
I
I
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
I
I
tipos podem ser: sı́ncrono ou assı́ncrono
fı́sica: cada escrita no disco é replicada em outro disco no
outro servidor
I
I
I
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
I
segmento de log de transação: quando um arquivo de log
de transação é arquivado, ele é aplicado no outro nó
I
I
archive timeout (longo)
buffer de log de transação: quando a transação é efetivada,
ela é transmitida e efetivada no outro nó
I
- 1 seg (curto)
Streaming Replication
Warm Standby (< 9.0)
segmento #1
aplicar em caso de desastre
segmento #2
Uso do servidor secundário
I
warm standby: o servidor secundário não aceita conexões
I
hot standby: o servidor secundário aceita conexões
Hot Standby
Warm Standby
principal
principal
réplica
réplica
Mais Alguns Conceitos...
I
alta disponibilidade: manter os serviços disponibilizados o
maior tempo possı́vel
I
balanceamento de carga: distribuir a carga de trabalho
entre 2 ou mais servidores
I
failover: processo de outro servidor assumir os serviços do
servidor principal quando o último falha
I
failback: processo de restaurar os serviços no servidor
principal para o estado anterior a falha
I
cascateamento: em replicação, servidor A replica para
servidor B, servidor B replica para servidor C e D e assim
sucessivamente
Evolução
I
8.0: warm standby
I
8.1: warm standby (melhorias)
I
9.0: replicação assı́ncrona e hot standby
I
9.1: replicação sı́ncrona
I
9.2: replicação sı́ncrona (remote write) e cascateamento
I
?.?: replicação lógica e gatilhos de eventos
Replicação até 8.4
1
2
3
4
5
6
7
8
9
I
pg standby (≥ 8.3)
I
restore command: script que espera indefinidamente arquivo
WAL
triggered = false ;
w h i l e ( ! NextWALFileReady ( ) && ! t r i g g e r e d )
{
s l e e p (100000L ) ;
/∗ w a i t f o r ˜ 0 . 1 s e c ∗/
i f ( CheckForExternalTrigger () )
triggered = true ;
}
if (! triggered )
CopyWALFileForRecovery ( ) ;
Replicação por Fluxo: Arquitetura
I
WALReceiver estabelece uma conexão (via libpq) com
servidor principal
I
servidor principal abre o processo WalSender para enviar WAL
ao servidor réplica
I
replicação sı́ncrona espera WAL ser escrito no disco do
servidor réplica
principal
réplica
postgres
wal
buffers
postgres
write?
fsync?
WAL
conexão
WALSender
WALReceiver
WAL
Replicação por Fluxo: Assı́ncrona
I
replicação por fluxo no PostgreSQL é assı́ncrona por padrão
I
se o servidor principal cair, algumas transações que foram
efetivadas podem não ter sido replicadas
I
a quantidade de dados perdidos é correspondente ao atraso da
replicação no momento da queda
Replicação por Fluxo: Sı́ncrona
I
confirma que todas as mudanças feitas na transação foram
transferidas para um servidor réplica
I
cada transação que modifica dados esperará a confirmação
que as mudanças foram escritas no log de transação de
ambos servidores
I
fornece um nı́vel mais alto de durabilidade
tempo da transação
I
I
I
I
I
I
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
I
servidor réplica aceita conexões para replicação de outros
servidores réplica
I
replicação em cascata é assı́ncrona
I
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
I
I
9.3: não será necessário refazer as réplicas
Como funciona a replicação por fluxo?
I
recuperação de registros do log de transação no servidor
secundário
I
entrega: arquivo ou fluxo (“stream”)
I
no primário: processo walsender
I
no secundário: processo walreceiver
I
privilégio REPLICATION (≥ 9.1)
I
configuração: recovery.conf e postgresql.conf
I
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 = ’*’
I
criar role para replicar dados
CREATE ROLE usuario LOGIN REPLICATION;
I
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
I
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/ \
[email protected]:/bd/secundario
$ pg_ctl start -D /bd/primario
server starting
Replicação por Fluxo: No Principal
I
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/ \
[email protected]:/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...
I
Slony-I
I
Londiste
I
pgpool-II
I
RubyRep
I
Postgres-XC
Slony-I: Introdução
I
sistema de replicação do principal para múltiplas réplicas
I
suporte a cascateamento e promoção de réplica
I
replica dados entre diferentes versões do PostgreSQL
I
replica dados entre diferentes sistemas operacionais e modelos
de servidores
I
replica somente algumas tabelas para réplica
I
replica diferentes conjuntos de tabelas para diferentes réplicas
I
servidores diferentes podem ser a origem dos dados para
diferentes conjuntos de tabelas
Slony-I: Ele não faz...
I
replica objetos grandes (aka blobs)
I
replica comandos DDL (por exemplo, CREATE TABLE,
ALTER TABLE e DROP TABLE)
I
replica alterações em roles
I
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
I
arquitetura shared nothing
I
multi-mestre sı́ncrono
escalável em leitura/escrita
I
I
I
”3,4x performance com 5 servidores comparado com um
servidor PostgreSQL”
local de tabelas transparente
I
I
tabelas replicadas
tabelas distribuı́das
I
baseado no PostgreSQL (atualmente 9.1)
I
mesma API para aplicações que já utilizam PostgreSQL
Postgres-XC: Arquitetura
Aplicações
Coordenador
Nó 1
Catálogo
Coordenador
Global
Catálogo
Nó 2
Local
GTM Proxy
Catálogo
Global
Catálogo
Local
GTM Proxy
servidor 1
servidor 2
GTM
Agenda
Introdução
Conceitos
Evolução
Ferramentas
Conclusão
Outras inúmeras perguntas...
I
A sua pergunta na lista pgbr-{geral, dev}
I
A sua pergunta na lista pgsql-{general, performance, hackers}
I
histórico das listas
blogs
I
I
I
I
http://planeta.postgresql.org.br
http://planet.postgresql.org
wiki
I
http://wiki.postgresql.org
A Timbira no PGDay-SP 2012
I
Desmistificando Replicação no PostgreSQL (Euler Taveira)
I
Fazendo uma manada de elefantes passar por baixo da porta
(Fabio Telles)
Perguntas
?
Euler Taveira de Oliveira
[email protected]
http://www.timbira.com.br