Desmistificando Replicação no PostgreSQL

Desmistificando Replica¸c˜

ao no PostgreSQL

Euler Taveira

Timbira - A empresa brasileira de PostgreSQL

Apresenta¸c˜

ao

I Euler Taveira

I Desenvolvedor PostgreSQL

I L´ıder do PostgreSQL Brasil

I @eulerto

I http://eulerto.blogspot.com I Timbira

I Diretor T´ecnico

I A empresa brasileira de PostgreSQL

I Consultoria

I Desenvolvimento

I Suporte 24x7

Sobre esta apresenta¸c˜

ao

I esta apresenta¸c˜ao est´a dispon´ıvel em: http://www.timbira.com.br/material

I esta apresenta¸c˜ao est´a sob licen¸ca Creative Commons Atribui¸c˜ao-N˜ao Comercial 3.0 Brasil :

http://creativecommons.org/licenses/by-nc/3.0/br

Agenda

O que ´

e?

I perguntas mais frequentes I curiosidades

I conceitos de bancos de dados I como fazer

O que n˜

ao ´

e?

I t´opicos avan¸cados

I compara¸c˜ao com solu¸c˜oes de outros SGBDs

I solu¸c˜oes de replica¸c˜ao a n´ıvel de sistema de arquivos I solu¸c˜oes de replica¸c˜ao a n´ıvel de hardware

Um pouco de teoria...

I ”Replica¸c˜ao significa que n´os armazenamos v´arias c´opias de uma rela¸c˜ao ou parti¸c˜oes dela em sites diferentes.”

I Motiva¸c˜ao:

I aumentar a disponibilidade

I problema na r´eplica

I falha de comunica¸c˜ao

I acelerar execu¸c˜ao de uma consulta

I r´eplica mais pr´oxima pode executar consulta mais r´apido

I balancear a carga no SGBD

I tolerˆancia a falhas (SPOF)

I Como manter a r´eplica quando a rela¸c˜ao ´e modificada?

I s´ıncrono

Atualizando dados em um SGBD distribu´ıdo

I comportar-se como um SGBD centralizado para usu´ario I problemas devem ser transparente para usu´ario

I problemas devem ser resolvidos a n´ıvel de implementa¸c˜ao I consultas:

I executar consultas sem se preocupar como e onde as rela¸c˜oes est˜ao armazenadas

I atualiza¸c˜oes:

I transa¸c˜oes devem continuar sendo atˆomicas apesar da replica¸c˜ao

I c´opias da rela¸c˜ao modificada devem ser atualizadas antes da efetiva¸c˜ao da transa¸c˜ao (replica¸c˜ao s´ıncrona)

I SGBDs distribu´ıdos comerciais adotaram replica¸c˜ao ass´ıncrona

I independˆencia dos dados distribu´ıdos

I implementa¸c˜ao mais eficiente do que s´ıncrona

I transa¸c˜ao que lˆe c´opias da mesma rela¸c˜ao pode obter registros diferentes

Replica¸c˜

ao S´ıncrona

I custo da replica¸c˜ao s´ıncrona ´e alto

I bloqueio exclusivo em todas as c´opias

I bloqueio ´e mantido at´e que todas as c´opias estejam bloqueadas

I uma falha de comunica¸c˜ao provoca uma recupera¸c˜ao em todas as r´eplicas que j´a haviam gravado os dados

I v´arias mensagens s˜ao trocadas at´e a efetiva¸c˜ao da transa¸c˜ao I replica¸c˜ao s´ıncrona ´e indesej´avel ou mesmo inalcan¸c´avel em

Replica¸c˜

ao Ass´ıncrona

I ´e bastante popular mesmo que c´opias diferentes da mesma rela¸c˜ao tenham registros diferentes por um curto per´ıodo de tempo

I viola o princ´ıpio da independˆencia dos dados distribu´ıdos I todavia, ´e aceit´avel na grande maioria dos cen´arios I Tipos:

I offline

M´

etodos de Replica¸c˜

ao

I offline: armazena os dados em fita (e regularmente guarda em outro local)

I consistˆencia de dados ´e boa (a n˜ao ser por erro humano ou backup corrompido)

I atualidade dos dados est´a prejudicada

I tempo de recupera¸c˜ao n˜ao ´e cr´ıtico

I online: c´opia de dados de um servidor para outro atrav´es de um link

I tempo de recupera¸c˜ao (minutos a horas) ´e cr´ıtico

I atualiza¸c˜ao dos dados em tempo real

I s´ıncrono: ↓ capacidade e performance da replica¸c˜ao, ↓ tempo de resposta do sistema

Replica¸c˜

ao Online

I tipos podem ser: s´ıncrono ou ass´ıncrono

I f´ısica: cada escrita no disco ´e replicada em outro disco no outro servidor

I hardware

I software

I l´ogica: aplica¸c˜ao ´e respons´avel por replicar e garantir que a escrita foi realizada em outro disco no outro servidor

Replica¸c˜

ao F´ısica: Hardware

nó A nó B

Replica¸c˜

ao F´ısica: Software

nó A nó B

Replica¸c˜

ao L´

ogica

Granularidade

I segmento de log de transa¸c˜ao: quando um arquivo de log de transa¸c˜ao ´e arquivado, ele ´e aplicado no outro n´o

I archive timeout (longo)

I buffer de log de transa¸c˜ao: quando a transa¸c˜ao ´e efetivada, ela ´e transmitida e efetivada no outro n´o

I _{- 1 seg (curto)}

Streaming Replication Warm Standby (< 9.0)

segmento #1 segmento #2

Uso do servidor secund´

ario

I warm standby: o servidor secund´ario n˜ao aceita conex˜oes I hot standby: o servidor secund´ario aceita conex˜oes

Hot Standby Warm Standby

principal

réplica

principal

Mais Alguns Conceitos...

I alta disponibilidade: manter os servi¸cos 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¸cos do servidor principal quando o ´ultimo falha

I failback: processo de restaurar os servi¸cos no servidor principal para o estado anterior a falha

I cascateamento: em replica¸c˜ao, servidor A replica para servidor B, servidor B replica para servidor C e D e assim sucessivamente

Evolu¸c˜

ao

I 8.0: warm standby

I 8.1: warm standby (melhorias)

I 9.0: replica¸c˜ao ass´ıncrona e hot standby I 9.1: replica¸c˜ao s´ıncrona

I 9.2: replica¸c˜ao s´ıncrona (remote write) e cascateamento I ?.?: replica¸c˜ao l´ogica e gatilhos de eventos

Replica¸c˜

ao at´

e 8.4

I pg standby (≥ 8.3)

I 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 ( 1 0 0 0 0 0 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 C o p y W A L F i l e F o r R e c o v e r y ( ) ;

Replica¸c˜

ao por Fluxo: Arquitetura

I WALReceiver estabelece uma conex˜ao (via libpq) com servidor principal

I servidor principal abre o processo WalSender para enviar WAL ao servidor r´eplica

I replica¸c˜ao s´ıncrona espera WAL ser escrito no disco do servidor r´eplica buffers wal WAL WALReceiver principal réplica postgres WALSender postgres WAL conexão write? fsync?

Replica¸c˜

ao por Fluxo: Ass´ıncrona

I replica¸c˜ao por fluxo no PostgreSQL ´e ass´ıncrona por padr˜ao I se o servidor principal cair, algumas transa¸c˜oes que foram

efetivadas podem n˜ao ter sido replicadas

I a quantidade de dados perdidos ´e correspondente ao atraso da replica¸c˜ao no momento da queda

Replica¸c˜

ao por Fluxo: S´ıncrona

I confirma que todas as mudan¸cas feitas na transa¸c˜ao foram transferidas para um servidor r´eplica

I cada transa¸c˜ao que modifica dados esperar´a a confirma¸c˜ao que as mudan¸cas foram escritas no log de transa¸c˜ao de ambos servidores

I fornece um n´ıvel mais alto de durabilidade I tempo da transa¸c˜ao

I transferir os dados entre servidor principal e r´eplica I escrever dados no log de transa¸c˜ao do servidor r´eplica

I mandar mensagem do servidor r´eplica para principal com ACK I escrever dados no log de transa¸c˜ao do servidor principal I transa¸c˜oes somente leitura, ROLLBACK e subtransa¸c˜oes n˜ao

Replica¸c˜

ao em Cascata

I servidor r´eplica aceita conex˜oes para replica¸c˜ao de outros servidores r´eplica

I replica¸c˜ao em cascata ´e ass´ıncrona

I n˜ao h´a configura¸c˜ao especial para habilitar a replica¸c˜ao em cascata

I promover um servidor r´eplica intermedi´ario termina as conex˜oes para replica¸c˜ao

Como funciona a replica¸c˜

ao por fluxo?

I recupera¸c˜ao de registros do log de transa¸c˜ao no servidor secund´ario

I entrega: arquivo ou fluxo (“stream”) I no prim´ario: processo walsender I no secund´ario: processo walreceiver I privil´egio REPLICATION (≥ 9.1)

I configura¸c˜ao: recovery.conf e postgresql.conf

I monitoramento: pg current xlog location (prim´ario) e pg last xlog {receive, replay} location (secund´ario)

Replica¸c˜

ao 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 LOGINREPLICATION;

I no pg hba.conf :

Replica¸c˜

ao por Fluxo: No Secund´

ario

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

Replica¸c˜

ao 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/ \

postgres@10.1.1.2:/bd/secundario $ pg_ctl start -D /bd/primario server starting

Replica¸c˜

ao 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/ \

postgres@10.1.1.2:/bd/secundario postgres=# select pg_stop_backup(); pg_stop_backup

---0/90D7950

Replica¸c˜

ao por Fluxo: No Secund´

ario

$ pg_ctl start -D /bd/secundario server starting

Algumas ferramentas...

Slony-I: Introdu¸c˜

ao

I sistema de replica¸c˜ao do principal para m´ultiplas r´eplicas I suporte a cascateamento e promo¸c˜ao de r´eplica

I replica dados entre diferentes vers˜oes do PostgreSQL

I replica dados entre diferentes sistemas operacionais e modelos de servidores

I replica somente algumas tabelas para r´eplica

I replica diferentes conjuntos de tabelas para diferentes r´eplicas I servidores diferentes podem ser a origem dos dados para

Slony-I: Ele n˜

ao faz...

I replica objetos grandes (aka blobs)

I replica comandos DDL (por exemplo, CREATE TABLE, ALTER TABLE e DROP TABLE)

I replica altera¸c˜oes em roles

I todavia, comandos DDL podem ser submetidos as r´eplicas manualmente utilizando o slonik

Postgres-XC

Postgres-XC

I arquitetura shared nothing I multi-mestre s´ıncrono I escal´avel em leitura/escrita

I ”3,4x performance com 5 servidores comparado com um servidor PostgreSQL”

I local de tabelas transparente

I tabelas replicadas

I tabelas distribu´ıdas

I baseado no PostgreSQL (atualmente 9.1)

Postgres-XC: Arquitetura

Agenda

Outras in´

umeras perguntas...

I A sua pergunta na lista pgbr-{geral, dev}

I A sua pergunta na lista pgsql-{general, performance, hackers} I hist´orico das listas

I blogs

I http://planeta.postgresql.org.br

I http://planet.postgresql.org I wiki

A Timbira no PGDay-SP 2012

I Desmistificando Replica¸c˜ao no PostgreSQL (Euler Taveira) I Fazendo uma manada de elefantes passar por baixo da porta

Perguntas

?

Euler Taveira de Oliveira euler@timbira.com.br http://www.timbira.com.br