4 Commits

Include renames

Author	SHA1	Message	Date
admin	7a06b040ad	postgresql-ha-staging.yaml: add primary_slot_name to fix real bootstrap failure ... Root cause of a real cutover run's failure: the standby_leader's basebackup from legacy completed, but its Postgres process then got permanently stuck in "starting" because legacy had no replication slot reserving WAL — normal WAL recycling (checkpoint_timeout=300s) deleted the segment needed to resume streaming during the 8-11 min basebackup window. This also explained why the cascade replica's own basebackup (which targets the standby_leader) failed with "database system is starting up" — one root cause, not two. Fix: created a physical replication slot (standby_leader_slot) on live production legacy, and added primary_slot_name: standby_leader_slot under bootstrap.dcs.standby_cluster in both patroni-0 and patroni-1's SPILO_CONFIGURATION so Patroni pins the slot automatically. Also bumped wal_keep_size to 4GB on legacy as defense-in-depth. Full incident detail documented in this file's header for future reference.	2026-08-04 20:04:01 -07:00
admin	4dcb3561ed	postgresql-ha-staging.yaml: switch from CLONE_WITH_BASEBACKUP to Patroni standby_cluster (continuous streaming, validated in pgha-test dry run) - closes pre-cutover write gap	2026-07-30 21:59:44 -07:00
admin	499402cd0d	postgresql-ha-staging.yaml: port dry-run fixes (bugs 1,2,4,5) - $$(...) escaping (incl. CLONE_PASSWORD), ETCD3_HOSTS, post_init_wrapper.sh SUPERUSER role fix	2026-07-30 15:56:43 -07:00
admin	f4f0749969	postgresql: add cutover staging compose (ADR-0001 Phase 3). Lives in cutover/ subdir — deliberately excluded from stack-deploy.sh folder merge. Deployed only by cutover script as separate postgresqlha stack.	2026-07-28 11:07:03 -07:00