Upgrade de versión mayor casi sin tiempo de inactividad con replicación lógica

Comando

# 0) On the old version wal_level = logical (restart); every table needs a PRIMARY KEY or REPLICA IDENTITY
# 1) Move roles and schema to the new version (a 'role postgres already exists' error is expected):
pg_dumpall -h <old_host> --globals-only | psql -h <new_host> -X -d postgres
pg_dump -h <old_host> --schema-only --create -d <db> | psql -h <new_host> -X -d postgres
# 2) Publication on the old version, subscription on the new version (initial copy + continuous stream):
psql -h <old_host> -d <db> -X -c "CREATE PUBLICATION upg_pub FOR ALL TABLES;"
psql -h <new_host> -d <db> -X -c "CREATE SUBSCRIPTION upg_sub CONNECTION 'host=<old_host> dbname=<db> user=<repl_user>' PUBLICATION upg_pub;"
# 3) Wait until all tables are 'r' (ready) and lag is ~0:
psql -h <new_host> -d <db> -X -c "SELECT srsubstate, count(*) FROM pg_subscription_rel GROUP BY 1;"
psql -h <old_host> -d <db> -X -c "SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag FROM pg_replication_slots WHERE slot_name = 'upg_sub';"
# 4) Cutover: stop application writes, confirm lag = 0, synchronize sequences (logical-sync-sequences)
# 5) Drop the subscription (the remote slot is dropped too), point the application to the new server:
psql -h <new_host> -d <db> -X -c "DROP SUBSCRIPTION upg_sub;"

Qué hace

Construye un clúster vacío en la nueva versión, traslada el esquema y transmite continuamente los datos desde la versión antigua con replicación lógica; solo el paso final de cambio (detener las escrituras, sincronizar las secuencias, redirigir) provoca una breve caída. Una segunda replicación en sentido inverso puede mantener abierta una vía de rollback.

Cuándo usarlo

Cuando la caída que requiere pg_upgrade es inaceptable, al cambiar a la vez a nuevo hardware/SO, o al saltar varias versiones mayores.

Precaución

El DDL, las secuencias, los large objects y el contenido de las materialized views no se replican; congele el esquema durante la migración. En tablas sin primary key/replica identity, UPDATE/DELETE fallan en el publicador. En bases de datos grandes la copia inicial tarda mucho y retiene WAL y catalog_xmin en el servidor antiguo. Cada base de datos necesita su propia publicación/suscripción. Compare el número de filas/checksums antes del cambio final.