Обновление мажорной версии почти без простоя через логическую репликацию

Команда

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

Что делает

Создаёт пустой кластер на новой версии, переносит схему и непрерывно передаёт данные из старой версии через логическую репликацию; короткий простой вызывает только финальный шаг переключения (остановка записи, синхронизация последовательностей, перенаправление). Вторая репликация в обратном направлении позволяет сохранить путь отката.

Когда использовать

Когда простой, требуемый pg_upgrade, неприемлем, при одновременном переходе на новое оборудование/ОС или при пропуске нескольких мажорных версий.

Внимание

DDL, последовательности, большие объекты и содержимое материализованных представлений не реплицируются; замораживайте схему на время миграции. На таблицах без первичного ключа/replica identity UPDATE/DELETE на издателе завершаются ошибкой. На больших базах начальное копирование занимает много времени и удерживает WAL и catalog_xmin на старом сервере. Каждой базе данных нужна своя публикация/подписка. Перед переключением сравните число строк/контрольные суммы.