PostgreSQL 9.4 - Replicação com slots

Este é um artigo demonstrando como fazer uma replicação de dados com slots, disponível a partir da versão 9.4, que permite diminuir o uso de wal_keep_segments para garantir o preenchimento de dados para o modo de espera em caso de atraso por replicação excessiva.

[ Hits: 13.635 ]

Por: Wendel em 13/01/2015


Configurando o mestre e o escravo



Configurando mestre

Utilizaremos o usuário postgres por ser "liberado" para acessar os arquivos de configuração do PostgreSQL:

su postgres

Desative o PostgreSQL:

sudo /etc/init.d/postgresql stop

Acesse o arquivo /etc/postgresql/9.4/main/postgresql.conf e altere os seguintes itens (não esquecer de descomentar eles retirando o "#" da frente caso tenham):

listen_address = "*" # ou aqui você coloque o IP dos servidores que acessaram, no caso utilizo * para todos
wal_level = logical
max_wal_senders = 3
max_replication_slots = 3 #Quantidade máxima de escravos que replicarão
hot_standby = on

Salvem e saiam do arquivo, agora acesse o arquivo /etc/postgresql/9.4/main/pg_hba.conf onde utilizaremos o usuário postgres para replicar os dados e acesso de fora do servidor, digite em qualquer parte do código (preferível na última linha):

host       replication       postgres       0.0.0.0/0     trust

No caso eu coloquei 0.0.0.0/0, mas você pode colocar o IP do escravo para caso seja exclusivo para ele. Inicie o servidor:

sudo /etc/init.d/postgresql start

Caso queira ver o status utilize:

pg_lsclusters

E confira se o status está online, seguimos agora para o próximo passo que é a configuração no escravo.

Configurando escravo - Finalizando

Pararemos o servidor caso em uso:

sudo /etc/init.d/postgresql stop

Novamente como no mestre, utilizaremos o usuário postgres, supondo que estamos na "home" do usuário e que ela seja na pasta /var/lib/postgresql, no ESCRAVO execute:

pg_basebackup -P -R -X stream -c fast -h XXX.XXX.XXX.XXX -U postgres -D 9.4/main/

No local de XXX.XXX.XXX.XXX coloquem o IP do servidor MESTRE (tá na cara, mas tem que dizer de qualquer modo) e aguardem.

No servidor MESTRE devemos acessar o PostgreSQL para "reservar o slot" para o usuário, portanto voltando ao MESTRE acesse o PostgreSQL e execute o que vem a seguir:

# psql -U postgres
SELECT * FROM pg_create_physical_replication_slot('DIGITE_UM_NOME_DE_USUARIO_PARA_ESCRAVO');

Só isso no mestre, agora voltando ao ESCRAVO, acesse o arquivo recovery.conf, ainda supondo que esteja na home do usuário postgres e que seja /var/lib/postgresql, acesse o arquivo 9.4/main/recovery.conf e acrescente a linha:

primary_slot_name = 'NOME_DE_USUARIO_DIGITADO_PARA_ESCRAVO_AQUI'

Salve o arquivo e saia, apenas isso. Agora sincronizaremos os dados DO servidor mestre PARA o escravo:

sudo rsync -av XXX.XXX.XXX.XXX:/etc/postgresql/ /etc/postgresql/

Pronto, a partir disso você já sincronizou os arquivos, inicie o servidor:

sudo /etc/init.d/postgresql start

Voltando para o servidor veremos o status da replicação:

# psql -U postgres
SELECT * FROM pg_stat_replication;

Onde deve aparecer:

-[ RECORD 1 ]----+------------------------------
pid              | 4265
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | XXX.XXX.XXX.XXX
client_hostname  |
client_port      | 63704
backend_start    | 2015-01-10 17:42:59.555191-05
backend_xmin     |
state            | streaming
sent_location    | 0/50DF5F8
write_location   | 0/50DF5F8
flush_location   | 0/50DF5F8
replay_location  | 0/50DF5F8
sync_priority    | 0
sync_state       | async


Onde XXX.XXX.XXX.XXX dessa vez é o IP do escravo, se o state diz que está em streaming já está funcionando a replicação, agora se quiser teste criando um banco de dados no servidor (obviamente que não tenha no escravo senão, não tem graça. :v)

CREATE DATABASE testereplicacao;

E confira se no ESCRAVO criou o mesmo banco de dados, se sim, a replicação já está funcionando. Caso queira ver quais slots de replicação estão sendo usados use:

SELECT * FROM pg_replication_slots;

Caso queira ver o status de replicação use:

SELECT * FROM pg_stat_replication;

Caso queira apagar um slot utilize:

SELECT pg_drop_replication_slot('DIGITE_O_NOME_DE_USUARIO_ESCOLHIDO_PARA_ESCRAVO');

Desculpem por possíveis erros de língua portuguesa, talvez falta de informação etc. Este é meu primeiro artigo então peço desculpas por tudo e obrigado por lerem até o final!

Página anterior    

Páginas do artigo
   1. Conceito e instalação
   2. Configurando o mestre e o escravo
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Pool de Conexões Transparentes no Postgres usando o pgpool

Postgres e os Sistemas Alterdata

Vacuum - otimizando sua base de dados PostgreSQL

Checklist de performance do PostgreSQL 8.0

HowTo: Como criar Cluster Linux - Ativo/Passivo para Postgres com DRBD, Pacemaker e Corosync

  
Comentários
[1] Comentário enviado por mineirobr em 13/01/2015 - 20:15h

Parabéns, muito bom.

[2] Comentário enviado por jcoli em 15/01/2015 - 10:30h

Muito bom... estou testando.


Jeferson Coli
---------------------
www.tecnocoli.com.br

[3] Comentário enviado por bmarquesm em 14/02/2015 - 22:02h

Uma pergunta: a replicação é em tempo real ou tem um certo tempo até a replicação começar a ser feita? Se sim, isso nao prejudicaria em questões de performance para aplicações com muito processamento no banco de dados?

[4] Comentário enviado por wotan em 17/02/2015 - 00:06h


[3] Comentário enviado por bmarquesm em 14/02/2015 - 22:02h

Uma pergunta: a replicação é em tempo real ou tem um certo tempo até a replicação começar a ser feita? Se sim, isso nao prejudicaria em questões de performance para aplicações com muito processamento no banco de dados?


Não, a replicação é feita em tempo real, o que muda é que, dependendo da quantidade de tempo em que um escravo fique desconectado, sem atualizar (tipo, muuuuuuuuuito tempo mesmo) o servidor mestre pode apagar esse "requerimento", ele ajuda tendo o controle de usuarios escravos para o mestre, tornando mais facil a transmissão e atualização de dados :v


[5] Comentário enviado por alubale em 18/06/2015 - 16:56h

Parabens pelo artigo, funcionou perfeitamente.

[6] Comentário enviado por YanSilva em 27/12/2015 - 20:00h

Olá Wendel, poderia me dar uma ajuda?

Seguinte: segui todos os passos a risca porém na hora de subir o slave, depois da sincronização, ocorre um erro por diferença entre os identificadores de master e do slave. Dei uma pesquisada e concluí que poderia ter sido um erro na hora da sincronização do /etc/postgresql/9.4/main. Então apaguei o diretório completo e sincronizei novamente pra ter certeza que os arquivos seriam realmente os do /etc/postgresql/9.4/main do master. Mesmo assim o erro persiste. Tens alguma ideia do que possa ser? Perdi alguns dias tentando resolver.

Parabéns pelo artigo!

[7] Comentário enviado por williamcmello em 16/01/2016 - 11:38h

Boa tarde,

Eu tenho um Banco de Dados de 220Gigas, eu tenho que copiar o banco para o servidor slave ou ele faz a cópia automaticamente??

Att,


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts