Dominando a Replicação do PostgreSQL: Tipos e Configuração Explicados

No mundo dos bancos de dados relacionais avançados de código aberto, o PostgreSQL se destaca por sua robustez, extensibilidade e recursos poderosos. Entre eles, a redundância de dados e a alta disponibilidade são primordiais para aplicações de missão crítica. A replicação do PostgreSQL é o mecanismo que permite que você atinja esses objetivos, copiando dados de um servidor PostgreSQL (o primário) para um ou mais outros servidores PostgreSQL (os réplicas ou standbys).

Este artigo irá aprofundar-se nos conceitos centrais da replicação do PostgreSQL, explorando os diferentes tipos disponíveis e fornecendo orientação prática sobre como configurá-los. Entender esses mecanismos é crucial para garantir que seus dados estejam sempre acessíveis, protegidos contra falhas de hardware e capazes de lidar com cargas de leitura crescentes. Abordaremos tanto a replicação de streaming quanto a replicação lógica, explicando seus casos de uso, vantagens e etapas de configuração.

Por Que a Replicação do PostgreSQL É Importante

Antes de mergulhar no 'como', é essencial entender o 'porquê'. A perda de dados ou o tempo de inatividade prolongado podem ter consequências graves para os negócios. A replicação aborda essas preocupações através de:

• Alta Disponibilidade (HA): Se o servidor primário falhar, um réplica pode ser promovido rapidamente para se tornar o novo primário, minimizando o tempo de inatividade.
• Recuperação de Desastres (DR): Os réplicas podem ser localizados em diferentes locais geográficos, protegendo seus dados contra desastres específicos do local.
• Escalabilidade de Leitura: Descarregar cargas de trabalho intensivas em leitura para os réplicas pode melhorar o desempenho do servidor primário, que permanece dedicado às operações de escrita.
• Proteção de Dados: A replicação atua como um backup contínuo, oferecendo uma cópia dos seus dados mais atualizada do que backups periódicos tradicionais.

O PostgreSQL oferece dois métodos principais de replicação: Replicação de Streaming e Replicação Lógica. Embora ambos atinjam a sincronização de dados, eles operam com base em princípios diferentes e são adequados para cenários distintos.

Replicação de Streaming (Replicação Física)

A replicação de streaming é a forma mais comum e fundamental de replicação no PostgreSQL. Ela funciona enviando registros do Write-Ahead Log (WAL) do servidor primário para um ou mais réplicas. Esses registros WAL representam cada alteração feita no banco de dados. Os réplicas, então, aplicam esses registros WAL aos seus próprios arquivos de dados, garantindo que permaneçam consistentes com o primário.

Tipos de Replicação de Streaming:

1. Replicação Síncrona: No modo síncrono, o servidor primário aguarda a confirmação de pelo menos um (ou um número especificado) dos réplicas de que os registros WAL foram recebidos e gravados em seu buffer WAL antes de confirmar o commit da transação ao cliente. Isso garante que as transações confirmadas existam em pelo menos um réplica, fornecendo o mais alto nível de consistência de dados.

   • Prós: Garante nenhuma perda de dados para transações confirmadas no réplica síncrono.
   • Contras: Pode introduzir latência nos commits de transação, pois o primário deve esperar pela confirmação do réplica.

2. Replicação Assíncrona: No modo assíncrono, o servidor primário envia registros WAL para os réplicas, mas não espera por confirmação antes de confirmar a transação. O primário confirma o commit ao cliente imediatamente após gravar o WAL localmente. Isso oferece menor latência, mas acarreta o risco de perda de dados se o primário falhar antes que os registros WAL sejam enviados e aplicados ao réplica.

   • Prós: Impacto mínimo na latência de commit de transação.
   • Contras: Potencial de perda de dados se o primário falhar e os registros WAL ainda não tiverem chegado ao réplica.

Configurando a Replicação de Streaming (Exemplo Assíncrono)

A configuração da replicação de streaming envolve configurar tanto os servidores primário quanto os de réplica. Aqui está um guia simplificado:

1. Configurar o Servidor Primário (postgresql.conf e pg_hba.conf)

No servidor primário, você precisa habilitar o arquivamento WAL e as conexões de replicação.

• Modificações no postgresql.conf:

  ```ini
  wal_level = replica # ou logical para replicação lógica
  max_wal_senders = 5 # Número de conexões de replicação simultâneas
  wal_keep_size = 512MB # Ou wal_keep_segments para versões mais antigas

  Para replicação síncrona, adicione:

  synchronous_standby_names = 'replica1,replica2'

  Ou para nome/prioridade de servidor específico:

  synchronous_standby_names = '1 (replica1), 2 (replica2)'

  archive_mode = on
  archive_command = 'cp %p /path/to/wal_archive/%f'
  `` *wal_level: Deve ser pelo menosreplicapara replicação de streaming. *max_wal_senders: Especifica quantos servidores standby podem se conectar simultaneamente. *wal_keep_size: Impede que os arquivos WAL sejam excluídos antes que os réplicas possam buscá-los (uma alternativa mais simples aarchive_commandpara configurações básicas, mas o arquivamento é recomendado para robustez). *archive_mode&archive_command`: Cruciais para recuperação point-in-time (PITR) e essenciais se um réplica ficar muito atrasado ou precisar ser reconstruído.

• Modificações no pg_hba.conf:

  Permita que o réplica se conecte para replicação. Substitua replica_ip_address pelo IP real do seu réplica.

  ```ini

  TYPE DATABASE USER ADDRESS METHOD

  host replication replication_user replica_ip_address/32 md5
  ```

  Você também precisará criar um usuário de replicação:

  sql -- No servidor primário: CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';

  Após modificar esses arquivos, recarregue a configuração do PostgreSQL:

  ```bash
  pg_ctl reload

  Ou reinicie o PostgreSQL se necessário

  ```

2. Preparar o Servidor Réplica

Antes de iniciar o réplica, ele deve ter um diretório de dados que seja uma cópia do diretório de dados do primário em um ponto específico no tempo. A maneira mais fácil é usar pg_basebackup.

• Pare o PostgreSQL no réplica (se estiver em execução).

• Faça um backup base:

  ```bash

  Certifique-se de que PGDATA esteja vazio ou removido primeiro

  pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P
  `` *-h,-p,-U: Especificam os detalhes de conexão do servidor primário. *-D: O diretório de dados para o réplica. *-Fp: O formato é plain. *-Xs: Usa TSL/WAL streaming. Equivalente à configuraçãoprimary_conninfopara streaming WAL. *-P: Mostra o progresso. * Você será solicitado a inserir a senha doreplication_user`.

3. Configurar o Servidor Réplica (postgresql.conf e recovery.conf ou postgresql.conf para PG12+)

• Modificações no postgresql.conf (para PG12+):

  ```ini
  hot_standby = on # Permite consultas somente leitura no réplica
  primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'

  Para replicação síncrona, adicione:

  primary_promote_delay = 10 # segundos

  Ou use um mecanismo de arquivo de gatilho

  `` *hot_standby: Habilita consultas somente leitura no standby. *primary_conninfo`: String de conexão para o servidor primário.

• recovery.conf (para versões do PostgreSQL anteriores à 12):

  Crie um arquivo recovery.conf no diretório de dados do réplica com o seguinte conteúdo:

  ```ini
  standby_mode = 'on'
  primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'

  Se estiver usando recuperação de arquivo em vez de streaming, você especificaria restore_command

  restore_command = 'cp /path/to/wal_archive/%f %p'

  recovery_target_timeline = 'latest'

  ```

  Para PG12+, primary_conninfo e hot_standby são definidos diretamente em postgresql.conf.

4. Iniciar o Servidor Réplica

Inicie o serviço PostgreSQL no réplica. Ele se conectará ao primário, receberá os registros WAL e começará a sincronizar. Você pode verificar os logs para confirmação.

Dica: Para HA robusta, considere usar ferramentas como Patroni ou repmgr, que automatizam o failover e o gerenciamento.

Replicação Lógica

A replicação lógica é uma forma de replicação mais flexível e granular introduzida no PostgreSQL 10. Em vez de replicar blocos inteiros de dados ou registros WAL, ela replica as alterações de dados com base em seu significado lógico (por exemplo, comandos INSERT, UPDATE, DELETE) no nível da linha. Isso é alcançado decodificando os registros WAL em um fluxo de alterações lógicas.

Principais Recursos e Casos de Uso:

• Replicação Seletiva: Você pode escolher quais tabelas ou até mesmo quais colunas replicar. Isso é altamente benéfico para mover dados seletivamente entre bancos de dados.
• Replicação Entre Versões: A replicação lógica pode replicar dados entre diferentes versões principais do PostgreSQL.
• Alterações de Esquema Seletivas: Você pode replicar alterações para bancos de dados ou esquemas específicos e até mesmo publicar apenas tabelas específicas.
• Transformação de Dados: Embora não seja integrada, a replicação lógica fornece uma base para processos ETL (Extract, Transform, Load) mais complexos.
• Replicação de um Primário para um Réplica que não é um clone completo: O banco de dados de destino não precisa ser uma cópia física completa da origem.

Como Funciona:

1. Publisher (Editor): O banco de dados de origem (primário) onde ocorrem as alterações de dados. Ele precisa de wal_level = logical. As alterações são decodificadas do WAL em um fluxo lógico.
2. Publication (Publicação): Um conjunto nomeado de tabelas no publisher cujas alterações serão replicadas.
3. Subscriber (Assinante): O banco de dados de destino (réplica) que recebe as alterações.
4. Subscription (Assinatura): Uma conexão no subscriber que se conecta ao publisher e aplica as alterações de uma publicação específica.

Configurando a Replicação Lógica

1. Configurar o Publisher (Servidor Primário)

• Modificações no postgresql.conf:

  ini wal_level = logical max_replication_slots = 10 # Para slots de replicação lógica max_wal_senders = 10 # Deve ser pelo menos max_replication_slots

• Criar uma Publicação:

  ```sql
  -- No banco de dados do publisher:
  CREATE PUBLICATION my_publication FOR TABLE
  table1,
  table2
  WITH (publish = 'insert,update,delete');

  -- Para todas as tabelas:
  -- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;
  ```

  Recarregue a configuração no publisher.

2. Configurar o Subscriber (Servidor Réplica)

• Certifique-se de que as tabelas de destino existam: O banco de dados do subscriber deve ter as tabelas de destino com o mesmo esquema do publisher. Você pode criá-las manualmente ou usar pg_dump para extrair o esquema.

• Criar uma Assinatura:

  sql -- No banco de dados do subscriber: CREATE SUBSCRIPTION my_subscription CONNECTION 'host=publisher_host_ip port=5432 user=replication_user password=your_password dbname=publisher_db' PUBLICATION my_publication;

  O replication_user precisa das permissões apropriadas no publisher.

  O PostgreSQL criará automaticamente um slot de replicação no publisher e começará a aplicar as alterações. Você pode monitorar o status da assinatura usando pg_stat_subscription no subscriber.

Dica: A replicação lógica requer a extensão logical decoding, que geralmente é integrada. Ela consome mais recursos do que a replicação de streaming, mas oferece maior flexibilidade.

Escolhendo o Método de Replicação Correto

• Replicação de Streaming: Ideal para alta disponibilidade e recuperação de desastres, onde você precisa de uma cópia exata, byte por byte, do primário. É mais simples de configurar para replicação de banco de dados completa e fornece a melhor escalabilidade de leitura para réplicas somente leitura.
• Replicação Lógica: Melhor para distribuição seletiva de dados, migrações, atualizações entre versões ou quando você precisa replicar apenas um subconjunto de dados. Permite cenários mais complexos, como replicar para esquemas diferentes ou realizar transformações de dados.

Conclusão

A replicação do PostgreSQL é um recurso poderoso que permite disponibilidade robusta de dados, recuperação e escalabilidade. Se você optar pela replicação abrangente de espelhamento de dados da replicação de streaming ou pela abordagem flexível e seletiva da replicação lógica, entender seus mecanismos e configurações é fundamental para manter um ambiente PostgreSQL saudável e resiliente. Ao implementar a replicação, você aumenta significativamente a tolerância a falhas e as capacidades de desempenho do seu banco de dados.

Sempre teste sua configuração de replicação detalhadamente, especialmente os cenários de failover, e monitore o atraso da replicação para garantir que seus réplicas estejam atualizados. O aprendizado contínuo e a adaptação aos recursos em evolução do PostgreSQL solidificarão ainda mais seu domínio deste sistema de banco de dados indispensável.