Postgres Remote Replica Docs for Data Center Failover + Failback - #910
Conversation
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 34236755 | Triggered | Username Password | 15ad7b4 | docs/guides/postgres/remote-replica/advanced-setup-yamls/pg-singapore-auth.yaml | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughAdds a PostgreSQL cross-cluster disaster recovery guide with shared TLS setup, Singapore and London manifests, bidirectional remote replication, failover, recovery, failback, validation, and cleanup procedures. ChangesPostgreSQL remote replica disaster recovery
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant pg-singapore
participant pg-london
participant Coordinator
pg-singapore->>pg-london: Stream cross-cluster WAL
Coordinator->>pg-london: Check replication lag
Operator->>pg-singapore: Delete failed primary
Operator->>pg-london: Promote to standalone primary
pg-london-->>Operator: Report ready and writable
Operator->>pg-singapore: Redeploy as remote replica
pg-london->>pg-singapore: Stream recovered WAL
Possibly related PRs
Suggested reviewers: ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Visit the preview URL for this PR (updated for commit b5bd6d7): https://kubedb-v2-hugo--pr910-remote-replica-pg-ru0wd5gj.web.app (expires Wed, 12 Aug 2026 10:30:00 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 0f29ae8ae0bd54a99bf2b223b6833be47acd5943 |
Re-ran the full guide end to end (setup, failover, reattach, failback) against the release PR stack before making these changes; every edit below states what that run actually showed. - Remote replica pod listings corrected from 1/1 to 2/2, and the "no coordinator" sentence replaced: remote replicas now run a pg-coordinator sidecar (no Raft) that handles pg_rewind/re-seed recovery, keeps the standby role label truthful, and logs replication lag. - deletionPolicy switched from Delete to Halt throughout. With retained PVCs the return legs of failover/failback reattach to existing data: ex-standbys follow the timeline history and the former primary is repaired in place with pg_rewind -- observed directly, no full re-seed on any of the six reattaching pods. With Delete every return leg silently re-seeds from scratch. - Removed the 11.1 "may stay NotReady, restart the pod" workaround note: the underlying promote issue is fixed by the init-container promote-before-writes change, and eight consecutive promotions across test cycles never reproduced it. - remote-config commands fixed: -y is a boolean confirmation skip, not an output filename; the output path is fixed to <dbname>-remote-config.yaml in the current directory. Added the -d host:port / --port note. - Auth secrets are now created from a shell variable instead of committed YAML files; the two files carrying a literal password are removed. - Step 8 gains the coordinator's lag-monitor log as a verification signal; Step 10 explains the retained-PVC reattach and the log lines to expect. - pg-singapore-remote-replica.yaml now references pg-singapore-auth for coherence (previously it pointed at pg-london-auth and only worked because both passwords must match). Signed-off-by: Tamal Saha <tamal@appscode.com>
Verified by a clean-room run of the guide exactly as written (fresh namespaces and CA, every step 1-11 from the guide's own files and commands; all sample counts reproduced 1000 through 1005 with no manual intervention). Two hardenings from that run: note that Raft may elect any pod as primary since the examples assume pod 0, and create the auth secrets with --save-config so the later kubectl apply from remote-config does not warn about a missing last-applied annotation. Signed-off-by: Tamal Saha <tamal@appscode.com>
Signed-off-by: souravbiswassanto saurov@appscode.com
Summary by CodeRabbit