Major-Version-Upgrade nahezu ohne Ausfallzeit mit logischer Replikation

Befehl

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

Was es tut

Baut einen leeren Cluster auf der neuen Version auf, überträgt das Schema und streamt Daten per logischer Replikation fortlaufend aus der alten Version; nur der finale Umstellungsschritt (Schreibvorgänge stoppen, Sequences synchronisieren, umleiten) verursacht einen kurzen Ausfall. Eine zweite Replikation in Gegenrichtung kann einen Rückweg offen halten.

Wann einsetzen

Wenn der von pg_upgrade verlangte Ausfall inakzeptabel ist, wenn gleichzeitig auf neue Hardware/ein neues OS umgezogen wird oder wenn mehrere Major-Versionen übersprungen werden.

Vorsicht

DDL, Sequences, Large Objects und Inhalte von Materialized Views werden nicht repliziert; friere das Schema während der Migration ein. Bei Tabellen ohne Primärschlüssel/Replica Identity schlagen UPDATE/DELETE auf dem Publisher fehl. Bei großen Datenbanken dauert die initiale Kopie lange und hält auf dem alten Server WAL und catalog_xmin zurück. Jede Datenbank braucht eine eigene Publication/Subscription. Vergleiche vor der Umstellung Zeilenzahlen/Prüfsummen.