1) O documento discute replicação e alta disponibilidade no PostgreSQL, incluindo replicação síncrona, assíncrona, log shipping e streaming replication. 2) É apresentada uma demonstração prática de configurar replicação assíncrona entre um servidor mestre e réplica utilizando log shipping. 3) Operações permitidas em hot standby como consultas SELECT são descritas.

1. Replicação
Alta disponibilidade
PostgreSQL
PostgreSQL o poderoso sistema de
banco de dados relacional de
código aberto.

2. Apresentação
• Johnes Castro Mendes
• 21 Anos
• Cursando Segurança da Informação
• Tecnisys Tecnologias Inovadoras
• Analista de Suporte em Banco de dados
• Trabalho com PostgreSQL desde da sua versão 9.5

3. Replicação nativa PostgreSQL
• Síncrona
• Assíncrona

4. Síncrona
Neste tipo de sincronização, a replicação da ação é feita instantaneamente.
Se alguma cópia do banco é alterada, essa alteração será imediatamente
aplicada a todos os outros bancos dentro da transação. A replicação
síncrona é apropriada em aplicações comerciais onde é exigido um nível de
atualização muito preciso em todos os servidores envolvidos.
Desvantagem
Existem algumas desvantagens neste tipo de replicação. Mas, dentre as
principais, podemos citar:
• Perda sensível da performance;

5. Assíncrona
Neste modelo a replicação não é instantânea. O replicador monta um histórico
das ações a serem replicadas e em um determinado momento é feita a
replicação entre as bases de dados relacionadas. A alteração será propagada e
aplicada para outra base em um segundo passo, dentro de uma transação
separada. Esta poderá ocorrer em segundos, minutos, horas ou até dias depois,
dependendo da configuração pré-estabelecida.
Desvantagem
• Consumo de recursos das máquinas envolvidas acima do normal no
momento da replicação;
Isso é um fator negativo, pois o SGBD perde o poder de resposta nos
momentos que está replicando. Logicamente, esta é uma verdade apenas para
grandes volumes de dados.
• As informações nas máquinas envolvidas não estarão o tempo todo
atualizadas.
Este é um dos grandes problemas da replicação, as máquinas envolvidas na
replicação ficarão desatualizadas até que o processo de replicação seja iniciado.

6. Log-Shipping Standby Servers
• Replicação assíncrona
• O arquivamento contínuo pode ser usado para criar ambientes de alta
disponibilidade, com um ou mais slaves (warm standby)
• O master opera em modo de arquivamento contínuo e os slaves
operam em modo de recuperação contínua, lendo os arquivos de WAL
da área de archive
• Oferece baixa complexidade de administração, bem como um baixo
impacto na performance do master.
• A diferença de dados entre o servidor master e os slaves pode ser
limitada através do parâmetro archive_timeout

7. Streaming Replication
• Replicação assíncrona
• A diferença entre o master e os slaves é menor
• Os slaves se conectam ao master, que copia os registros de WAL a
medida que são gerados, sem necessitar que estejam completados
• Os slaves não recebem apenas os registros de WAL vindos diretamente
do master, mas também da área de archive. Mesmo que a conexão
streaming caia, os slaves continuarão em estado de recuperação, lendo os
WALs no archive

8. Cascading Replication
• Replicação assíncrona
• Permite que um slave aceite conexões de replicação e copie osregistros
de WAL para outros slaves
• Permite diminuir o número de conexões diretas ao master, bem comoos
overheads de banda entre locais de rede
• Não existe limite para o número de slaves cascateados

9. Hot Standby
• Configuração dos slaves que permite conexão para a execução de
consultas, enquanto o servidor está em modo de recuperação
• É necessária a mudança do parâmetro hot_standby para “on”
(postgresql.conf)
• Todas as conexões são estritamente readonly. Nem escritas nas tabelas
temporárias são permitidas

10. Vamos para a prática!!!

11. Vamos para a prática!!! - MASTER
Já com o PostgreSQL instalado, vou criar um novo cluster e vou chama-lo
de MASTER.
$ /usr/pgsql-9.6/bin/initdb /var/lib/pgsql/9.6/master/
Vou configurar o nosso MASTER para arquivar os dados, a partir desses
logs de transação, vamos realizar a replicação.
$ vi /var/lib/pgsql/9.6/master/postgresql.conf

12. Vamos para a prática!!! - MASTER
listen_addresses = '*' # Esse parâmetro do qual o postgres aceita conexões.
A opção '*' aceita todas as conexões.
wal_level = replica # Determina a quantidade de informação
que é escrita para o WAL. A opção replica adiciona os registros necessários
para o arquivamento de WAL, bem como as informações necessárias para
executar consultas de somente leitura em um servidor standby.
checkpoint_timeout = 1min
archive_mode = on # Quando archive_mode está habilitado, os
segmentos WAL completos são enviados para o armazenamento de
arquivos (Archiver ou arquivamento) configurando archive_command.

13. Vamos para a prática!!! - MASTER
archive_command = 'cp %p /var/lib/pgsql/9.6/archive_master/%f' #
Comando shell local para executar o arquivaemento dos arquivos WAL
concluídos.
archive_timeout = 30seg # Quando esse parâmetro for maior que zero, o
servidor alternará para um novo arquivo de segmento sempre que esses
segundos tiverem decorrido desde o último switch de arquivo de
segmento e houver qualquer atividade de banco de dados, incluindo um
único checkpoint.
max_wal_senders = 2 # Especifica o número máximo de conexões
simultâneas de servidores standby ou de clientes de backup baseados em
fluxo contínuo (ou seja, o número máximo de processos simultaneamente
em execução do remetente WAL). Wal_level deve ser definido como réplica
ou superior para permitir conexões de servidores standby.

14. Vamos para a prática!!! - MASTER
Editar o pg_hba:
host replication postgres 127.0.0.1/32 trust

15. Vamos para a prática!!! - Archiver
Vamos realizar uma replica a partir de um archiver que foi configurado no
archive_command no postgresql.conf do cluster master.
Criar o diretório onde vai ser arquivado o nossos WALs
$ mkdir archive_master/
$ chown -R postgres:postgres /var/lib/pgsql/9.6/archive_master/
$ chmod 700 -R /var/lib/pgsql/9.6/archive_master/
OBS: A opção -R é recurssiva, onde no caso do chmod dá permissão na
diretório e nos seus sub_diretórios.

16. Vamos para a prática!!! - Replica
Criar e dar permissões no diretório da Replica
$ mkdir /var/lib/pgsql/9.6/replica
$ chown -R postgres:postgres /var/lib/pgsql/9.6/replica
$ chmod 700 -R /var/lib/pgsql/9.6/replica
Fazer um backup online do Master, com o pg_start_backup vamos indicar
para o banco que vamos iniciar o backup.
$ psql -p 5432 -c "select pg_start_backup ('bk_master' || now())"

17. Vamos para a prática!!! - Replica
Realizar a cópia online do Master
$ cp -rpv /var/lib/pgsql/9.6/data/* /var/lib/pgsql/9.6/replica/
Indicar para o banco master que finalizamos o backup
psql -p 5432 -c "select pg_stop_backup()"

18. Vamos para a prática!!! - Replica
Remover do diretório da replica os arquivos da pasta pg_xlog e os
arquivos postmaster.pid e postmaster.opts
$ rm -rf pg_xlog/*
$ rm -f postmaster.pid postmaster.opts
Alterar parâmetros no arquivo postgresql.conf da replica
port = 5433 # Especifica a porta que o seu
cluster irá executar.
hot_standby = on # Especifica se você pode se conectar ou
executar consultas durante a recuperação. Esse parâmetro só pode ser
definido no início do servidor. Só tem efeito durante a archive recovery ou
modo standby.

19. Vamos para a prática!!! - Replica
Criar e editar o arquivo recovery.conf
vi recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=127.0.0.1 port=5432 user=postgres'
restore_command = 'scp /var/lib/pgsql/archiver/%f %p'
Iniciar o banco replica
$ pg_ctl -D /var/lib/pgsql/9.6/replica start

20. Hot Standby – Operações Permitidas
• Consultas: SELECT, COPY TO
• Cursores: DECLARE, FETCH, CLOSE
• Parâmetros: SHOW, SET, RESET
• Gerenciamento de transações: BEGIN, END, ABORT, STAR
TRANSACTION, SAVEPOINT, RELEASE, ROLLBACK TO SAVEPOINT,
EXCEPTION
• LOCK TABLE: ACCESS SHARE, ROW SHARE ou ROW EXCLUSIVE.
• Planos e recursos: PREPARE, EXECUTE, DEALLOCATE, DISCARD
• Plugins e extensões: LOAD

21. Obrigado pela
atenção de todos
Johnes Castro
Johnes.mendes@tecnisys.com.br
https://www.linkedin.com/in/joh
nes-castro-1144ba103/