DBAtlas · Atlas de operações de banco de dados

Upgrade de versão major com downtime quase zero via replicação lógica

PostgreSQLUpgrade

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

O que faz

Cria um cluster vazio na nova versão, move o schema e transmite continuamente os dados da versão antiga com replicação lógica; apenas a etapa final de virada (parar gravações, sincronizar sequences, redirecionar) causa uma indisponibilidade curta. Uma segunda replicação na direção inversa pode manter aberto um caminho de rollback.

Quando usar

Quando a indisponibilidade exigida pelo pg_upgrade é inaceitável, ao migrar para novo hardware/SO ao mesmo tempo ou ao pular várias versões major.

Atenção

DDL, sequences, large objects e o conteúdo de materialized views não são replicados; congele o schema durante a migração. Em tabelas sem primary key/replica identity, UPDATE/DELETE falham no publisher. Em bancos grandes a cópia inicial demora e segura WAL e catalog_xmin no servidor antigo. Cada banco precisa de sua própria publication/subscription. Compare contagens de linhas/checksums antes da virada.

Abrir no DBAtlas →

Relacionados