Replicação de Banco de Dados

Replicação de Banco de Dados
Replicar é preciso
* Aumenta a disponibilidade
- Mesmo site
- Site remoto
* Distribuição de carga
- Leitura
- Escrita (maior desfio)
- Funções
Replicação Nativa do PostgreSQL
* Master - Múltiplos Slaves
- A partir do Master
- A partir de outro Slave (Cascata)
A replicação no postgreSQL só existe, desde que se tenha um log shipping ou geração de
arquivamento, a partir do postgreSQL 9.0 tem a replicação por fluxo embutido.
No PostgreSQL 9.4 temos a replicação de master para múltiplos slaves e um slave pode se
conectar a um master, tendo um slave na rede pode se conectar outros slaves a um slave
tendo assim uma replicação em cascata.
*Streaming
- Replica utilizando uma conexão normal PostgreSQL
- Replica todo o Cluster
Enquanto no Log Shipping tem que aguardar o arquivo estar completo para ser transmitido e
por padrão o PostgreSQL é de 16Mb a informação não é replicada.
Ja no Cluster o que alguns consideram desvantagem é que ele não atualiza somente uma
tabela ou uma instrução ele atualiza tudo .
* Permite Hot-Standby
Os servidores slaves vão permitir leitura ou seja pode-se dar um SELECT no servidor.
* Replica Síncrona
Os servidores Slaves vão estar no mesmo tempo do servidor Master, na falha do servidor
Master os servidores Slaves tem o mesmo conteúdo que o Master tinha.
Este processo tem uma perda de desempenho de aproximadamente 50%, pois temos que
aguardar a informação ser salva no Master e depois no Slave isso estamos falando em
servidores no mesmo site, com redes com boas performances.
* Replicação Assíncrona
No caso da replicação assíncrona o servidor Slave vai estar sempre com um delay em relação
ao Master, em alguns casos, onde os bancos com pouca escrita este delay é praticamente
imperceptível, porem ela é utilizada na grande maioria em replicações de longa distância com
latências muito altas.
Além da replicação nativa no PostgreSQL, temos também a replicação lógica.
Se houver a necessidade de uma maior granularidade.
* Slony
- Replicação Master múltiplos Slaves
Pode ser escolhido até a tabela especifica para ser replicada.
* Bucardo
- Master múltiplos Slaves
- Master multi-Master (Divisão de Processamentos)
Muito utilizado em excesso de funções onde exige um processamento muito alto.
* xDB - EnterpriseDB
- Assim como Bucardo + suporte a replicação SGDBs
Faz replicação entre bancos de dados diferentes. ex.(De um PostgreSQL para um Oracle).
- Ferramenta Gráfica de Administração
Uma configuração rapida de replicação.
Servidor Mater
Ajustar o arquivo postgreSQL.conf, a partir de um sql padão.
* listen_addresses, wal_level, wal_keep_segments e max_wal_senders
Ajustar o arquivo pg_hba.conf
* Criar entrada para o Usuario de replicação.
Reiniciar o PostgreSQL.
Criar o Usuario de replicação.
1º Passo
Editar o arquivo postgresql.conf
a) Localize a linha listen_addresses, normalmente ela esta comentada, descomente a linha e
altere o 'localhost' para 'localhost,IP_DA_MAQUINA'.
b) Localize a linha wal_level, normalmente ela esta comentada, descomente a linha e altere
após o sinalde iqual a palavra Minimal para hot_standby, se não o postgresql nao replica.
c) Localize a linha wal_keep_segments, altere o valor de 0 (zero) para exemplo 10 em um
banco que escreve pouco e podendo alterar para 100 ou 1000 dependendo da quantidade de
gravação gerada pelo banco.
d) Localize a linha max_wal_senders, descomente a linha e informe a quantidade de replicas
que se vai ter.
Após editar salva e sai do arquivo.
2º Passo
Editar o arquivo pg_hba.conf
Vai ao final do arquivo e de entrada com a seguinte linha:
host replication
replicador
0.0.0.0/0
trust
Onde host é o nome da entrada, replication é o nome do banco de dados fictício para que o
postgres entenda que será replicado, 0.0.0.0/0 deve ser inserido o ip do servidor slave (que vai
receber a replicação) e trust é para não pedir senha, pode ser colocado md5 também.
Após editar salva e sai do arquivo.
3º Passo
Reinicie o banco.
4º Passo
Criar o usuário padrão.
a) sudo postgres
b) psql
c) create user replicador replication;
d) \q
Servidor Slave
* Parar o postgreSQL
* Fazer pg_basebackup
* Criar recovery.conf
* Ajustar mascara do diretório
* Iniciar o PostgreSQL
1º Passo
Parar o PostgreSQL
service postgresX stop
2º Passo
Remover o banco de dados atual que tenha no banco.
rm -RF /var/lib/pgsql/9.4/data/*
Logar como Postgres, pois ele é o dono do cluster para usar a ferramenta pg_basebackup.
pg_basebackup -D /var/lib/pgsql/9.4/data/ -h 0.0.0.0 -U replicador
Para quem não conhece o pg_basebackup o parâmetro -D e o diretório onde o backup vai cair,
o diretório deve estar vazio por esse motivo foi removido o conteúdo da pasta /data, o -h será
o ip do servidor Master, e o -U nome do usuário criado para replicação.
3º Passo
Criar um arquivo recovery.conf no diretório /var/lib/pgsql/9.4/data/ com o seguinte conteúdo.
#recovery.conf
standby_mode=on
primary_conninfo='host=IP_Master user=replicador application_name=nome_servidor_slave'
trigger_file='/tmp/pgtrigger'
Salve e saia.
4º Passo
Reiniciar o postgreSQL
Como saber se o postgres esta replicando?
No Slave digite:
ps aux | grep postgres
se tiver a linha
postgres: wal receiver process
No Master digite
ps aux | grep postgres
se tiver a linha “wal send process replicador ip_slave” esta replicando
Como Promover um Slave a Master?
Como saber se uma maquina esta em modo de replicação?
No banco de dados entre com o código: select pg_is_in_recovery();
A função ira retornar um "t" de true se a maquina for slave.
Promovendo:
Como usuário postgres é criado um arquivo trigger.
touch /tmp/pgtrigger "Este foi o nome configurado no recovery.conf"
pronto agora ele já é master.