Mise à niveau majeure quasi sans interruption par réplication logique

Commande

# 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;"

Ce que fait la commande

Crée un cluster vide dans la nouvelle version, y transfère le schéma et diffuse en continu les données depuis l'ancienne version par réplication logique ; seule l'étape finale de bascule (arrêt des écritures, synchronisation des séquences, redirection) provoque une courte interruption. Une seconde réplication en sens inverse peut garder ouverte une voie de retour arrière.

Quand l'utiliser

Lorsque l'interruption exigée par pg_upgrade est inacceptable, lors d'un passage simultané à un nouveau matériel/OS, ou pour sauter plusieurs versions majeures.

Attention

Le DDL, les séquences, les large objects et le contenu des vues matérialisées ne sont pas répliqués ; gelez le schéma pendant la migration. Sur les tables sans clé primaire/replica identity, les UPDATE/DELETE échouent sur le publisher. Sur les grosses bases, la copie initiale est longue et retient WAL et catalog_xmin sur l'ancien serveur. Chaque base nécessite sa propre publication/souscription. Comparez nombres de lignes/checksums avant la bascule.