repmgr architecture, repmgr.conf reference & repmgrd failover hub.
repmgr
repmgrd + Witness & Barman Stack
repmgr CLI & Extension
recommendedStores cluster topology, upstream node IDs, priority weights, and location strings inside a shared PostgreSQL extension schema.
repmgrd Failover Daemon
supportedMonitors upstream availability via `connection_check_type` (`ping`, `connection`, `query`) and orchestrates standby election and `follow_command`.
Witness Server Quorum
recommendedLightweight tie-breaker node for 2-data-node topologies that prevents an isolated standby across a WAN link from self-promoting.
Barman Standby Cloning
supportedClones new standbys directly from a central Barman backup catalog and fetches missing WAL segments automatically when replication slots lag.
We harden repmgr 5.x deployments and execute seamless repmgr-to-Patroni migrations.
- P1: 15 min · P2: 30 min
- Initial-response targets under a 24x7 support agreement (P3: 60 min, P4: 90 min); 2 to 4 hours during covered business hours.
- No External DCS Required
- Unlike Patroni, repmgr requires no etcd/Consul cluster, relying on witness nodes, `location` tags, and custom fencing scripts.
- repmgr or Patroni?
- We support established repmgr 5.x clusters and also execute zero-drama migrations from repmgr to Patroni + etcd.
Selected clients
Production Failure Modes
Six repmgr pitfalls we diagnose in production.
Because repmgr operates without an external etcd cluster, its failover safety depends on witness placement, `primary_visibility_consensus`, and self-fencing disconnect scripts.
Split-brain dual primaries after a cross-AZ network partition
2 nodes report Role = primary in repmgr cluster show
A 2-node cluster (1 primary + 1 standby) was deployed with `failover = automatic` and no `witness` server or `primary_visibility_consensus = true`.
Register a `repmgr witness` node in the primary's availability zone, set matching `location` strings in `repmgr.conf`, and enable `primary_visibility_consensus = true`.
`repmgr standby switchover` fails halfway through planned maintenance
ERROR: unable to connect to remote host via SSH
Unlike Patroni's REST API, `repmgr standby switchover` requires passwordless SSH (`postgres` OS user) between all cluster nodes and a working `pg_ctl` / systemd `service_stop_command`.
Always run `repmgr standby switchover --dry-run` before maintenance; verify bilateral SSH keys, `sudo systemctl` permissions, and `repmgrd_service_stop_command`.
Sibling standbys stay attached to the old primary after a failover
Standby 3 still streaming from demoted Node 1
`follow_command` in `repmgr.conf` is missing `--upstream-node-id=%n` or `repmgrd` is not running on the secondary standbys to receive the new leader notification.
Configure `follow_command = '/usr/bin/repmgr standby follow -f /etc/repmgr/16/repmgr.conf -W --upstream-node-id=%n'` and verify `repmgrd` is active on every node.
Demoted primary continues accepting writes from local app connections
Diverged WAL timelines & errant transactions on old leader
`repmgrd` promoted the standby, but because repmgr has no built-in kernel watchdog, the isolated old primary remained running and reachable by local app pods.
Implement `child_nodes_check_interval` with `child_nodes_disconnect_command` on the primary so it shuts itself down when standbys disconnect, and route apps through HAProxy or PgBouncer.
False-positive failover triggered during heavy checkpoint I/O
unable to reconnect to upstream node after 3 attempts
`connection_check_type = query` timed out when PostgreSQL backends were briefly busy, and `reconnect_attempts * reconnect_interval` was set under 15 seconds.
Use `connection_check_type = ping` (`PQping()`), which checks postmaster responsiveness without spawning a full backend query, and set `reconnect_attempts = 6` / `reconnect_interval = 5`.
Inactive replication slots left on old primary fill disk after switchover
pg_wal directory exhausts available disk capacity
`use_replication_slots = true` created physical slots on Node 1, and after switching over to Node 2, stale inactive slots remained on the former primary.
Run `repmgr cluster cleanup` and verify `repmgr node check --replication-slots` as part of every post-switchover runbook, plus set `max_slot_wal_keep_size` in `postgresql.conf`.
Response Targets & Incident Triage
Published P1 to P4 response targets and the first hour of a P1.
When a switchover stalls mid-execution or `repmgr cluster show` flags a diverged primary, you reach a senior PostgreSQL DBRE directly.
2 to 4 hours
Initial response target
Initial-response target during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30).
15 minutes
Initial response target
Initial-response target for P1 incidents where your service agreement includes 24x7 on-call.
Published Severity Matrix (under a 24x7 support agreement)
Production database down, primary unreachable, data corruption risk, or active failover event.
Severe latency spike, replication lag climbing rapidly, connection exhaustion, or degraded HA node.
Non-critical slow query regression, staging issue, backup warning, or replication check alert.
Configuration question, index advisory, planned schema review, or general operational request.
Our engineering team is in India; business-hours coverage is Mon–Fri 09:00–18:00 IST (UTC+5:30), and 24x7 on-call is available under your service agreement. Every 24x7 response target above applies under a 24x7 support agreement and measures initial engineer response, not full incident resolution.
01 · Page
0 to 15 minutes (P1 target under a 24x7 support agreement)
Your alert reaches a senior PostgreSQL/repmgr DBRE directly, with no Tier-1 ticket triage queue.
02 · Triage
15 to 30 minutes
We run `repmgr cluster show`, `repmgr service status`, and `repmgr node check` across all nodes to identify split-brain primaries, paused daemons, or broken slots.
03 · Mitigate
30 to 60 minutes
We pause `repmgrd` (`repmgr service pause`), fence any rogue primary, re-point standbys via `repmgr standby follow`, or rejoin a diverged old primary using `repmgr node rejoin --force-rewind`.
04 · Review
Within 24 hours
We deliver a written post-incident finding with hardened `repmgr.conf` timers, witness/location settings, and `child_nodes_disconnect_command` self-fencing hooks.
Architecture & Operational Scope
Six repmgr engineering areas we configure and operate.
We harden repmgr 5.x clusters with witness servers, self-fencing scripts, and Barman backup integration, or migrate you cleanly to Patroni when your architecture requires etcd consensus.
`repmgrd` Automatic Failover & Consensus
Configure `repmgrd` with `primary_visibility_consensus`, `connection_check_type = ping`, and priority weights so promotions are deterministic.
- Self-fencing on isolated primaries via `child_nodes_disconnect_command`.
- Automated sibling standby re-parenting via `follow_command`.
Witness Node & `location` Split-Brain Guardrails
Eliminate WAN split-brain promotions in 2-node + 1-witness or multi-datacenter PostgreSQL deployments.
- `repmgr witness register` placement inside the primary's failure domain.
- Datacenter `location` tagging so cross-region DR standbys never auto-promote on WAN blips.
Zero-Drama `repmgr standby switchover` Runbooks
Execute planned primary/standby role swaps for OS patching and hardware maintenance with pre-flight dry-run validation.
- Automated `--dry-run` checks for SSH connectivity, replication lag, and slot health.
- Coordinated `--siblings-follow` and PgBouncer `PAUSE`/`RESUME` integration.
Barman Backup & Standby Cloning Integration
Pair `repmgr` with Barman so standby nodes clone from your backup server instead of stressing the production primary.
- `barman_server` and `barman_host` configuration in `repmgr.conf`.
- Automatic WAL fallback via `barman-wal-restore` when streaming replication lags.
`repmgr node rejoin --force-rewind` Healing
Recover demoted primaries rapidly after an unplanned failover using `pg_rewind` orchestration built into `repmgr node rejoin`.
- Pre-requisite validation of `wal_log_hints = on` and `data_checksums`.
- Automated cleanup of orphaned replication slots via `repmgr node check`.
repmgr to Patroni Modernization
Outgrowing SSH-dependent switchovers? We migrate live `repmgr` clusters to Patroni + etcd v3 without rebuilding your standbys.
- Side-by-side etcd v3 bootstrap and Patroni adoption of existing PostgreSQL data directories.
- Transition from custom VIP scripts to HAProxy `:8008` HTTP health probes.
Interactive Cluster States & Reference repmgr.conf
How repmgr behaves across witness quorum, 2-node split-brain, and switchover.
Simulate a healthy 3-node witness topology, an unfenced 2-node split-brain failure, and a dry-run verified `repmgr standby switchover`, followed by our reference `repmgr.conf`.
repmgr + Witness Quorum & Switchover Simulator
Application and routing
Node 1 (primary) and Witness (Node 3) reside in `dc1`; Node 2 (standby) streams in `dc1` while Node 4 (`dc2` DR) has `failover=manual`.
Node 1 · pg-1 (Primary · dc1)
repmgrd monitoring connected standbys
child_nodes_connected_min_count = 1
Node 2 · pg-2 (Standby · dc1)
failover = automatic · priority = 100
primary_visibility_consensus = true
Node 3 · pg-witness (Witness · dc1)
Tie-breaker metadata instance
Prevents isolated standby promotion
Node 1 (primary) and Witness (Node 3) reside in `dc1`; Node 2 (standby) streams in `dc1` while Node 4 (`dc2` DR) has `failover=manual`.
Application and routing
Without a witness node or `child_nodes_disconnect_command`, a network glitch between Node 1 and Node 2 causes Node 2 to promote while Node 1 stays writable.
Node 1 · pg-1 (Isolated Primary)
Still running & accepting local writes
No child_nodes_disconnect_command set
Network Link (dc1 <-> az2)
Transient 35s packet loss
Exceeds reconnect_attempts * interval
Node 2 · pg-2 (Promoted Standby)
Runs repmgr standby promote
Starts Timeline 3 independently
Without a witness node or `child_nodes_disconnect_command`, a network glitch between Node 1 and Node 2 causes Node 2 to promote while Node 1 stays writable.
Application and routing
During planned maintenance, `repmgr standby switchover --siblings-follow` pauses `repmgrd`, demotes Node 1, promotes Node 2, and re-attaches Node 1 via `repmgr node rejoin`.
Node 2 · pg-2 (New Primary)
Promoted cleanly via switchover
PgBouncer/HAProxy updated via hook
Node 1 · pg-1 (Demoted to Standby)
Follows Node 2 automatically
Zero WAL divergence
Node 3 · Witness & Siblings
--siblings-follow updated upstream_node_id
repmgrd resumed across cluster
During planned maintenance, `repmgr standby switchover --siblings-follow` pauses `repmgrd`, demotes Node 1, promotes Node 2, and re-attaches Node 1 via `repmgr node rejoin`.
Production Configuration Specimen · repmgr 5.5
Hardened repmgr.conf with Visibility Consensus & Primary Self-Fencing
1. Reference /etc/repmgr/16/repmgr.conf
/etc/repmgr/16/repmgr.conf
# /etc/repmgr/16/repmgr.conf (Hardened Production Reference) node_id = 2 node_name = 'pg-node-2' conninfo = 'host=10.0.7.12 user=repmgr dbname=repmgr connect_timeout=2' data_directory = '/var/lib/postgresql/16/main' location = 'dc1' priority = 100 use_replication_slots = true # Failover & Consensus Guardrails failover = 'automatic' connection_check_type = 'ping' reconnect_attempts = 6 reconnect_interval = 5 primary_visibility_consensus = true standby_disconnect_on_failover = true # Self-Fencing When Primary Loses All Standbys child_nodes_check_interval = 5 child_nodes_connected_min_count = 1 child_nodes_disconnect_timeout = 20 child_nodes_disconnect_command = '/usr/local/bin/fence_isolated_primary.sh %p' # Promotion & Sibling Re-Parenting Commands promote_command = '/usr/bin/repmgr standby promote -f /etc/repmgr/16/repmgr.conf --log-to-file' follow_command = '/usr/bin/repmgr standby follow -f /etc/repmgr/16/repmgr.conf --log-to-file --upstream-node-id=%n' # Systemd Service Control for Switchovers service_start_command = 'sudo systemctl start postgresql@16-main' service_stop_command = 'sudo systemctl stop postgresql@16-main' service_restart_command = 'sudo systemctl restart postgresql@16-main' service_reload_command = 'sudo systemctl reload postgresql@16-main'
2. Operator switchover & node rejoin runbook
repmgr CLI Operations
# 1. Inspect cluster node roles, upstream assignments, and repmgrd status repmgr -f /etc/repmgr/16/repmgr.conf cluster show repmgr -f /etc/repmgr/16/repmgr.conf service status # 2. Audit node health, replication lag, and orphaned replication slots repmgr -f /etc/repmgr/16/repmgr.conf node check # 3. Validate a planned switchover with --dry-run (verifies SSH, lag, and pg_ctl) repmgr -f /etc/repmgr/16/repmgr.conf standby switchover --siblings-follow --dry-run # 4. Execute the controlled switchover repmgr -f /etc/repmgr/16/repmgr.conf standby switchover --siblings-follow # 5. Rejoin a former primary after an unplanned failover using pg_rewind repmgr -f /etc/repmgr/16/repmgr.conf node rejoin -d 'host=10.0.7.12 user=repmgr dbname=repmgr' --force-rewind
Shared Responsibility & Platforms
What your team owns and what JusDB owns.
Managed cloud databases automate much of the infrastructure layer, but your team still owns query performance, capacity, cost, and incident decisions. We manage repmgr deployments on Debian/Ubuntu, RHEL/Rocky/AlmaLinux, AWS EC2, GCP Compute Engine, and Azure VMs.
| Operational Layer | Customer Team | JusDB DBRE Team |
|---|---|---|
| Application Routing (PgBouncer / HAProxy / VIP) | Point application services at the cluster routing endpoint | Wire `promote_command` and `event_notification_command` to update PgBouncer or HAProxy |
| `repmgr.conf` & `repmgrd` Daemon Tuning | Approve maintenance windows and infrastructure PRs | Configure `reconnect_attempts`, `primary_visibility_consensus`, and `child_nodes_disconnect_command` |
| SSH Keys & Systemd Sudoers Setup | Authorize `postgres` user SSH and scoped systemd `sudoers` rules | Verify bilateral SSH and `--dry-run` readiness for `repmgr standby switchover` |
| Witness Server & Barman Integration | Provide witness VM and Barman backup storage | Register witness node, configure `barman-wal-restore`, and test standby cloning |
| 24x7 Monitoring & Incident Response (where contracted) | Receive Slack/PagerDuty notifications on SLA events | Monitor `repmgr node check`, replication slots, and respond within P1-P4 SLA targets |
Customer Boundary
What stays in your control
- Set business priorities, application requirements, and release plans
- Approve production changes, except routine actions you have pre-approved
- Own your cloud accounts, access policies, and vendor relationships
- Decide when maintenance can happen and how quickly service must recover
- Move the work in-house or to another provider after your agreement's notice period, with your data returned or deleted and the transition help your agreement sets out (Terms, section 8)
JusDB Execution Scope
What our DBREs execute for you
- Monitor database health, investigate alerts, and involve the right people
- Review query performance, replication, capacity, and backup health
- Carry out approved changes and update the operating instructions they affect
- Report completed work, open risks, and recommended next steps
Replication Manager Comparison & Engagement Paths
repmgr vs alternatives and how to engage JusDB.
Compare repmgr against Patroni, pg_auto_failover, and Stolon, then choose between hardening your repmgr cluster, migrating to Patroni, or starting with a free HA audit.
| Evaluation Vector | JusDB repmgr DBRE | Patroni / Cloud HA | Scripted / Keepalived |
|---|---|---|---|
| DCS Dependency & Operational Footprint | Zero external DCS requirement; cluster metadata stored natively in PostgreSQL tables (repmgr.nodes) with minimal resource and operational overhead | Requires separate 3-to-5 node etcd or Consul clusters with independent raft quorum maintenance, TLS certificates, and backup regimes | Homegrown scripts running without state awareness, prone to divergent node records and uncoordinated failovers |
| Automated Failover & Quorum Safety | repmgrd daemon fine-tuning with primary_visibility_consensus, location weighting, and multi-node quorum verification to prevent false promotions | Patroni provides strict DCS leader locks; cloud HA relies on opaque vendor hypervisor health probes with unpredictable failover windows | Crude cron scripts or bash pings triggering catastrophic premature failovers on transient packet drops |
| Standby Node Provisioning & Barman Sync | Automated repmgr standby clone with native Barman integration, streaming delta catchup, and cascading standby topology mapping | Requires custom pgBackRest restore hooks or full disk snapshots incurring heavy I/O spikes on the primary database | Manual pg_basebackup invocations saturating production network bandwidth and primary CPU without bandwidth rate limits |
| Node Fencing & Split-Brain Mitigation | Custom failover scripts integrated with STONITH power fencing, network routing isolation, and repmgr witness node arbitration | Patroni uses Linux softdog/watchdog kernel fencing; cloud managed services isolate nodes at hypervisor storage plane | No node isolation; former primary continues processing writes after network recovery, creating unrecoverable split-brain data loss |
| Operational Simplicity & DBRE Tooling | Standardized repmgr CLI runbooks (repmgr standby switchover, cluster show) with short planned switchovers and topology drift checks | Complex patronictl multi-layered CLI or proprietary cloud console interfaces with opaque state transitions | Ad-hoc pg_ctl promote commands leaving standby nodes in detached, unreplicating orphan states requiring manual rebuilds |
| Monitoring & Incident Response | Continuous repmgr node event auditing, replication slot lag alerting, and senior DBREs on your incident bridge. Initial-response targets: 2 to 4 hours in covered business hours; 15 minutes for P1 incidents with 24x7 on-call. Targets, not resolution guarantees. | Standard cloud support tickets with multi-hour triage queues and zero root-cause replication stream recovery assistance | Application developers attempting to recover broken WAL replication streams and mismatched timeline IDs at 3 AM |
repmgr Audit, Witness Setup or Patroni Migration
Fixed-scope engagement to eliminate split-brain risks in your `repmgr` cluster or migrate cleanly to Patroni + etcd.
- Audit of `repmgr.conf`, witness node registration, and primary self-fencing hooks.
- Validation of `repmgr standby switchover --siblings-follow` and Barman cloning.
- Optional live migration path from `repmgr` to Patroni + HAProxy.
Ongoing PostgreSQL & repmgr Support
Named senior PostgreSQL DBREs operating your `repmgr` replication topologies and Barman backups under one SLA.
- 15-minute P1, 30-minute P2, 60-minute P3, and 90-minute P4 response targets under a 24x7 support agreement.
- Planned switchovers, `repmgr node rejoin --force-rewind` recovery, and slot cleanup.
- 24x7 monitoring of `repmgrd` daemon state and WAL retention where contracted.
Free repmgr & Failover Safety Audit
Running a 2-node `repmgr` setup without a witness or self-fencing script? Let a senior PostgreSQL DBRE review your config.
- Inspection of `repmgr.conf`, `repmgr cluster show`, and `repmgr node check` output.
- Actionable recommendations to close split-brain and SSH switchover failure gaps.
- 30-minute engineering readout with copy-pasteable configuration fixes.
Procurement and security
Ready for legal and security review.
- Mutual NDA before any access
- Named individual accounts only
- Read-only access by default
- ISO 27001 & SOC 2 Type II: aligned, certification in progress
Mutual NDA before any access
We sign a mutual NDA before viewing schemas, logs, slow-query captures, or cloud topology.
Least-privilege, named credentials
Engineers connect through your bastion, VPN, or SSM using named accounts with read-only permissions by default.
Change control & approval gates
Production DDL, parameter changes, and failovers follow your change-management workflow with rollback steps prepared first.
Named leadership & direct escalation
Engagements are led by named senior database reliability engineers in India with direct Slack, Teams, and PagerDuty channels.
repmgr Technical & Operational FAQ
Frequently asked repmgr questions.
Synced 1-to-1 with our structured FAQPage schema. Need help configuring a witness server or migrating from repmgr to Patroni? Talk with our PostgreSQL DBRE team.
Still have a question?
Ask it on a scoping call. No production access needed.
Book a 30-min scoping call (opens Google Calendar in a new tab)repmgr vs Patroni: when should we use repmgr and when should we choose Patroni?
How do we prevent split-brain in a 2-node repmgr cluster?
Why does `repmgr standby switchover` require passwordless SSH?
How does `repmgr` integrate withPgBouncer or HAProxy when a failover happens?
How does `repmgr node rejoin --force-rewind` work after an unplanned failover?
What are JusDB's SLA response targets for repmgr and PostgreSQL incidents?
Related Spokes, Tools & Reference Hubs
Continue exploring PostgreSQL replication & HA.
Explore Patroni consensus failover, PgBouncer connection pooling, and PostgreSQL configuration tuning.
Patroni Architecture Reference Hub
Compare repmgrd witness voting against Patroni + etcd v3 leases and Linux watchdog fencing.
Patroni Consulting Services
Fixed-scope engagements to migrate legacy repmgr clusters to Patroni + HAProxy.
PgBouncer Reference Hub
Wire repmgr `event_notification_command` hooks into PgBouncer `PAUSE`/`RECONNECT`/`RESUME`.
PostgreSQL Replication Architecture
Streaming replication, physical/logical slots, and Barman PITR backup design.
PostgreSQL Config Optimizer
Generate tuned postgresql.conf parameters for WAL senders, checkpoints, and memory.
Open-Source Database Upgrade Hub
Execute PostgreSQL major version upgrades across repmgr clusters using pg_upgrade or logical replication.
Ready to Harden Your repmgr Cluster?
Get a senior PostgreSQL DBRE to review your repmgr.conf and witness topology.
Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.