Sistema de Replicação do C3SL - Replication Failover¶
Objetivos¶
1 - Ter uma estrutura master slave
2 - Caso ocorra uma falha na master, a slave deve virar new-master que seja acessível por postgresql.c3sl.ufpr.br
3 - Caso necessario, a master original deve sincronizar os dados e a new master deve virar a slave original
Links¶
Dependências¶
[1] PostgreSQL, 16.0-1, Sistema de Gerenciamento de Banco de Dados
Métodos¶
Existem diferentes formas de montar um serviço de replicação, cada uma delas com seu caso de uso. Inicialmente os métodos são divididos em replicação física e replicação lógica.
Replicação Física¶
Para a replicação física as alterações são feitas a nivel de armazenamento. Mudanças são replicadas por cópia do WAL do servidor principal para os servidores em standby. Com isso as servidoras em standby oferecem uma cópia exata do servidor principal. Além disso, possui baixo overhead por realizar as operações em baixo nivel. Normalmente utilizado para casos de desastre.
Replicação Lógica¶
Para a replicação lógica as alterações funcionam com base em detectar alterações utilizando mecanismos como triggers ou recursos de decodificação de logica interna. Normalmente utilizado para casos como integração de dados ou datawarehousing.
Replicação Física (Streaming/Log Shipping)¶
Para casos de recuperação a desastres será utilizado a replicação física, das quais possui tanto replicação por streaming quanto por log shipping. Por streaming as copias dos arquivos WAL são contínuas, enquanto que por log shipping as copias são realizadas periódicamente por lotes. Devido ao menor estresse de rede, maior controle e do servidor primário não precisar esperar os servidores em standby para realizar commits nas transações será utilizado log shipping.
Configuração¶
Duas máquinas distintas host1 (primario) e host2 (standby), uma instância do postgres na porta 5432 na host1 e conexão com rsync do host1 para o host2 sem senha.
Usuário de replicação¶
Criar um usuário de replicação no host1:
CREATE ROLE replica WITH REPLICATION LOGIN PASSWORD 'rep_password';
Configuração de acesso¶
Adicionar acesso do usuário rep_user ao arquivo pg_hba.conf no host1:
host replication replica host2.c3sl.ufpr.br scram-sha-256
Configurações do servidor primario (postgresql.conf)¶
Adicione as seguintes configurações ao arquivo de configuração no host1:
#┌────────────┐
#│ REPLICACAO │
#└────────────┘
archive_mode = off
primary_conninfo = 'host=primary.domain.com port=5432 user=replica password=rep_password'
# Uncomment as replication
#hot_standby = on
#hot_standby_feedback = on # In case of replication error, feedback
max_standby_streaming_delay = 30s #Maximum latency for streaming backups
recovery_min_apply_delay = 1
Cópia do cluster (host2)¶
Acesse a maquina de replicação (host2), crie um cluster utilizando os binários de criação do postgres, delete o diretório de dados e utilize pg_basebackup para criar uma cópia do cluster onde ficava o diretório de dados.
A opção --datadir dira ao cluster onde os dados ficam, caso não seja especificado, por padrão será criado na home do postgres em /var/lib/postgres.
Observe que a opção -X no pg_basebackup está como fetch, ou seja, log shipping. Caso fosse streaming seria -X stream.
# List clusters
pg_lsclusters
# Create a cluster
pg_createcluster 16 main --datadir=/home/postgres/16/main
# Remove directory data
rm -rf /home/postgres/16
# Copy all data from primary
pg_basebackup -h primary.domain.com -U replica -X fetch -v -R -W -D /home/postgres/16/main
# Create the file standby.signal in the standby host if it doesn't exists.
touch /home/postgres/16/main/standby.signal
E finalmente inicie a instância no host2. Com isso o host2 deverá estar bloqueado a escritas e devidamente copiando os arquivos WAL do host1.
Consistência do pg_hba¶
TODO: Conforme novos acessos são adicionados no pg_hba da servidora principal, os mesmos acessos precisam ser atualizados no pg_hba das servidoras em standby. Pesquisar métodos.
Promote do servidor standby¶
TODO: Automatizar promote em falhas do servidor primario