Logical replication no PostgreSQL: seletiva, entre versões e sem downtime

Se você já precisou atualizar o PostgreSQL entre versões major quase sem downtime, ou copiar apenas algumas tabelas para outro banco, a replicação física não ajuda — mas a lógica sim. Ela trabalha no nível de linha, entre versões, e é o padrão moderno para migrações sem downtime.

Lógica vs física: escolha a ferramenta certa

A replicação física (streaming) copia o cluster inteiro, byte a byte, só na mesma versão. A replicação lógica trabalha no nível de linhas e tabelas: ela decodifica o WAL em mudanças lógicas (INSERT/UPDATE/DELETE) e as reaplica via SQL. Isso libera três coisas que a física não faz:

• Replicar algumas tabelas, não o banco inteiro.
• Replicar entre versões major (15 → 16), a base dos upgrades sem downtime.
• Replicar para um banco que também aceita escritas próprias (consolidação, sharding).

1. No publicador (publisher)

-- postgresql.conf
wal_level = logical

-- depois crie uma publicação
CREATE PUBLICATION sales_pub FOR TABLE orders, order_items;
-- ou tudo:  CREATE PUBLICATION all_pub FOR ALL TABLES;

2. No assinante (subscriber)

As tabelas de destino já precisam existir com esquema compatível (a replicação lógica não copia DDL):

CREATE SUBSCRIPTION sales_sub
  CONNECTION 'host=pub.internal dbname=app user=replicator password=secret'
  PUBLICATION sales_pub;

Na criação, o assinante faz uma cópia inicial dos dados existentes e depois transmite as mudanças contínuas. Acompanhe o progresso com:

SELECT * FROM pg_stat_subscription;
SELECT srrelid::regclass, srsubstate FROM pg_subscription_rel;

srsubstate = 'r' significa que a tabela está totalmente sincronizada e replicando ao vivo.

Upgrade de versão major sem downtime

O caso de uso matador: subir 15 → 16 com segundos de downtime.

1. Monte um cluster novo PostgreSQL 16.
2. Recrie o esquema lá (pg_dump --schema-only).
3. Configure replicação lógica 15 → 16; deixe a cópia inicial + catch-up terminar.
4. Quando o lag for ~0, pare as escritas, deixe as últimas mudanças drenarem e aponte a aplicação para o 16.

Limitações a planejar

• Sem replicação de DDL. Mudanças de esquema precisam ser aplicadas dos dois lados manualmente, na ordem certa.
• Sequences não avançam no assinante — ajuste-as antes de promovê-lo.
• Replica identity: UPDATE/DELETE precisam de chave primária ou REPLICA IDENTITY FULL na tabela de origem.
• Cada subscription mantém um replication slot no publicador — um assinante abandonado prende WAL para sempre.

O slot que devora seu disco

Esse último ponto é o incidente número um da replicação lógica: um assinante some, seu slot para de avançar e o publicador retém WAL até o pg_wal encher o disco e o primário travar. O PG Monitoring acompanha o tamanho de WAL retido e a inatividade de cada replication slot, e alerta sobre um slot travado muito antes de ele ameaçar o primário.