Alte Primary nach einem Failover mit pg_rewind als Replica wieder einbinden

Befehl

# Prerequisite (must be set BEFORE the incident): wal_log_hints = on OR data checksums; full_page_writes = on
pg_controldata $PGDATA | grep -E 'wal_log_hints|checksum'
# 1) The old primary must be stopped:
pg_ctl -D $PGDATA stop -m fast
# 2) Dry run first:
pg_rewind --target-pgdata=$PGDATA --source-server='host=<new_primary_host> port=5432 user=postgres dbname=postgres' --progress --dry-run
# 3) Actual rewind + standby configuration (standby.signal + primary_conninfo):
pg_rewind --target-pgdata=$PGDATA --source-server='host=<new_primary_host> port=5432 user=postgres dbname=postgres' --progress --write-recovery-conf
# 4) Review postgresql.auto.conf copied from the source (port, primary_slot_name), then start:
pg_ctl -D $PGDATA start

Was es tut

Macht das Datenverzeichnis der alten Primary mit der neuen Primary konsistent, indem die nach dem Abzweigpunkt der Timeline geänderten Blöcke von der neuen Primary kopiert werden; macht sie binnen Minuten ohne vollständiges Basebackup zur Replica.

Wann einsetzen

Wenn die alte Primary nach einem Failover/Promote zurückkommt und mit abweichenden Änderungen hinter der neuen Timeline liegt.

Vorsicht

Transaktionen, die nach dem Failover auf der alten Primary verblieben und die neue Primary nie erreicht haben, werden endgültig entfernt. pg_rewind kopiert auch Konfigurationsdateien (postgresql.conf, postgresql.auto.conf, pg_hba.conf) von der Quelle; korrigiere vor dem Start Port- und Slot-Einstellungen. Ist seit dem Abzweigpunkt benötigtes WAL nicht mehr auf der Quelle, hole es mit -c (--restore-target-wal) aus dem Archiv. Die Quellverbindung braucht einen Superuser oder eine Rolle mit den in der Dokumentation genannten Funktionsprivilegien. In Patroni geschieht das automatisch mit use_pg_rewind: true.