Replicação: conceitos de primary e replica

1. Fundamentos da Replicação em Banco de Dados

1.1 Definição e objetivos da replicação

Replicação em banco de dados é o processo de copiar e manter dados sincronizados entre múltiplos servidores. Seus principais objetivos incluem:

  • Alta disponibilidade: Se o servidor primário falhar, uma réplica pode assumir rapidamente
  • Balanceamento de carga: Consultas de leitura podem ser distribuídas entre várias réplicas
  • Tolerância a falhas: Múltiplas cópias dos dados protegem contra perda de informações
  • Recuperação de desastres: Réplicas em localizações geográficas distintas garantem continuidade

1.2 Diferença entre replicação síncrona e assíncrona

Na replicação síncrona, o primary só confirma uma transação após garantir que pelo menos uma réplica recebeu os dados. Isso garante consistência forte, mas aumenta a latência das escritas.

Na replicação assíncrona, o primary confirma a transação imediatamente, sem aguardar confirmação da réplica. Oferece menor latência, mas com risco de perda de dados em caso de falha.

1.3 Modelos de replicação

  • Primário-único (single-master): Apenas um nó aceita escritas. É o modelo mais comum e simples de gerenciar.
  • Multi-mestre (multi-primary): Vários nós aceitam escritas. Oferece maior disponibilidade, mas exige resolução de conflitos.

2. Arquitetura Primary (Mestre)

2.1 Características do nó primary

O nó primary é o servidor que aceita operações de leitura e escrita. Todas as alterações nos dados ocorrem primeiro no primary antes de serem propagadas para as réplicas.

-- Verificar se o servidor é o primary
SELECT pg_is_in_recovery();

-- Resultado: false indica que é o primary
 pg_is_in_recovery 
-------------------
 f

2.2 Papel do WAL (Write-Ahead Log)

O WAL é o mecanismo central da replicação no PostgreSQL. Antes de qualquer alteração ser aplicada aos arquivos de dados, ela é registrada no WAL. As réplicas consomem esses registros para replicar as mudanças.

-- Verificar o WAL atual no primary
SELECT pg_current_wal_lsn();

-- Exemplo de saída
 pg_current_wal_lsn 
--------------------
 0/4A1B2C3

2.3 Gerenciamento de conexões e transações no primary

O primary gerencia conexões de clientes e transações normalmente. Para replicação, ele mantém conexões dedicadas (senders) para cada réplica conectada.

-- Listar conexões de replicação no primary
SELECT client_addr, state, sent_lsn, write_lsn 
FROM pg_stat_replication;

   client_addr   | state  | sent_lsn  | write_lsn 
-----------------+--------+-----------+-----------
 192.168.1.101   | streaming | 0/4A1B2C3 | 0/4A1B2C4
 192.168.1.102   | streaming | 0/4A1B2C3 | 0/4A1B2C3

3. Arquitetura Replica (Escravo)

3.1 Tipos de réplicas

  • Hot standby: Réplica que aceita consultas de leitura enquanto aplica o WAL
  • Warm standby: Réplica que aplica o WAL mas não aceita conexões de leitura
  • Cold standby: Réplica que não está em execução, apenas mantém os arquivos de dados

3.2 Réplica como leitora (read-only)

Réplicas no modelo hot standby aceitam apenas consultas SELECT. Tentativas de escrita resultam em erro:

-- Tentativa de escrita em uma réplica
INSERT INTO usuarios (nome) VALUES ('João');

-- Resultado:
ERROR:  cannot execute INSERT in a read-only transaction

3.3 Sincronização de dados: streaming replication vs. log shipping

Streaming replication: A réplica se conecta diretamente ao primary e recebe o WAL em tempo real.

Log shipping: Arquivos WAL completos são transferidos periodicamente para a réplica.

-- Configuração de streaming replication na réplica (postgresql.conf)
primary_conninfo = 'host=192.168.1.100 port=5432 user=replicator password=senha'
primary_slot_name = 'replica_1'

4. Mecanismos de Transferência de Dados

4.1 Fluxo do WAL do primary para a réplica

O processo ocorre em etapas: o primary escreve no WAL, a réplica solicita os registros através de streaming, e aplica as mudanças localmente.

4.2 Parâmetros de configuração essenciais

# No primary (postgresql.conf)
wal_level = replica
max_wal_senders = 5
wal_keep_size = 1024

# Na réplica (postgresql.conf)
hot_standby = on
primary_conninfo = 'host=192.168.1.100 port=5432 user=replicator'

4.3 Monitoramento do lag de replicação

-- No primary: verificar lag das réplicas
SELECT client_addr,
       pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS send_lag,
       pg_wal_lsn_diff(pg_current_wal_lsn(), write_lsn) AS write_lag,
       pg_wal_lsn_diff(pg_current_wal_lsn(), flush_lsn) AS flush_lag,
       state
FROM pg_stat_replication;

-- Na réplica: verificar lag de aplicação
SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;

5. Failover e Promoção de Réplica

5.1 Cenários de falha do primary

Quando o primary falha, é necessário promover uma réplica para se tornar o novo primary. O failover pode ser planejado (manutenção) ou não planejado (falha de hardware).

5.2 Processo de promoção manual

-- Na réplica a ser promovida (como superusuário do sistema)
pg_ctl promote -D /var/lib/postgresql/data

-- Ou via comando SQL (se conectado via hot standby)
SELECT pg_promote();

5.3 Uso de ferramentas externas

Patroni e repmgr automatizam o processo de failover, monitoramento e gerenciamento de clusters replicados.

# Exemplo de comando repmgr para verificar status do cluster
repmgr -f /etc/repmgr.conf cluster show

# Exemplo de failover manual com repmgr
repmgr -f /etc/repmgr.conf standby promote -n replica2

6. Gerenciamento e Manutenção em Ambiente Replicado

6.1 Adição e remoção de réplicas

Para adicionar uma nova réplica, utiliza-se pg_basebackup:

# No servidor da nova réplica
pg_basebackup -h 192.168.1.100 -D /var/lib/postgresql/data -U replicator -P -R

6.2 Backup em ambiente replicado

Realizar backups em réplicas reduz a carga no primary:

# Backup na réplica (com pg_dump)
pg_dump -h 192.168.1.101 -U backup_user -Fc database_name > backup.dump

6.3 Atualizações de versão no cluster

O processo típico envolve: atualizar réplicas primeiro, promover uma réplica atualizada, e depois atualizar o antigo primary.

7. Considerações de Performance e Segurança

7.1 Impacto na latência de escritas

A replicação síncrona adiciona latência às escritas no primary. O parâmetro synchronous_standby_names define quais réplicas devem confirmar:

synchronous_standby_names = 'replica_1, replica_2'

7.2 Configuração para consistência forte

# No primary
synchronous_commit = on
synchronous_standby_names = 'ANY 1 (replica_1, replica_2)'

7.3 Segurança na comunicação entre nós

# Configuração de SSL para replicação
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'

# No pg_hba.conf
hostssl replication replicator 192.168.1.0/24 md5

Referências