repmgr PostgreSQL High Availability Services
In short: repmgr is an open-source toolset for administering PostgreSQL streaming-replication clusters. Its CLI registers nodes, clones standbys, promotes replicas, and runs planned switchovers; the optional repmgrd daemon can monitor nodes and initiate failover. A DBRE design still needs routing, fencing, backups, failure tests, and DBA-owned recovery and change controls.
JusDB database SREs design and validate repmgr around the required failure model, PostgreSQL topology, network, client routing, recovery objectives, and operator responsibilities.
What is repmgr?
repmgr combines a PostgreSQL extension, metadata, a command-line client, and the optional repmgrd daemon. The CLI handles replication-administration tasks such as registration, clone, follow, promotion, rejoin, and switchover. repmgrd monitors nodes and can initiate a configured failover process.
Because repmgr does not use an external consensus DCS, topology visibility and isolation controls deserve careful attention. A witness can contribute another observation point, but fencing, routing, backups, restore testing, and old-primary handling remain explicit operator responsibilities.
How repmgr works in production
repmgr automates selected PostgreSQL replication tasks; it does not make the surrounding availability system self-validating. The daemon policy, witness, fencing, client routing, WAL, backup, and recovery paths must be tested as one system.
PostgreSQL Metadata
Register primary, standby, and witness records with controlled privileges, extension lifecycle, and metadata checks.
repmgrd Failover
Define monitoring, reconnect behavior, candidate selection, location, visibility, event hooks, and promotion gates.
Switchover and Rejoin
Validate prerequisites, sibling behavior, routing, WAL continuity, demotion, rewind or reclone, and rollback.
Witness and Fencing
Use witness observations where appropriate and pair repmgr controls with tested infrastructure fencing.
Backup-Assisted Cloning
Integrate a documented Barman clone path where suitable without conflating standby creation with recoverable backup.
Monitoring and Ownership
Track daemon, node, replication, WAL, routing, backup, and fencing state with named DBA actions.
repmgr vs Patroni
The tools use different coordination and management models. Select from measured recovery behavior, dependency ownership, platform integration, routing, fencing, and team procedures—not a generic simplicity score. Review the dedicated Patroni service page for its current behavior and requirements.
| Criterion | repmgr | Patroni |
|---|---|---|
| Coordination model | Cluster metadata in PostgreSQL; no external consensus DCS | Leader lock and dynamic configuration in a supported DCS |
| Automation | CLI operations plus optional repmgrd monitoring and failover | Continuous member control loop and optional automatic failover |
| Management interface | repmgr CLI, repmgrd, and PostgreSQL metadata | REST API and patronictl |
| Fencing model | External fencing and topology controls remain the operator's responsibility | DCS lock with optional Linux watchdog; infrastructure controls still matter |
| Deployment fit | Commonly used on hosts or VMs with PostgreSQL streaming replication | Hosts, VMs, containers, and Kubernetes with a supported coordination design |
| Decision basis | Dependency footprint, operational control, and acceptable failover model | DCS ownership, automation, routing, and failure behavior |
repmgr architecture decision criteria
repmgr may fit when
- • PostgreSQL streaming replication and host-level operations are already well understood.
- • The team wants CLI-led administration with optional repmgrd automation.
- • Witness, fencing, routing, backup, and rejoin behavior can be explicitly owned and tested.
- • Recovery objectives match the measured candidate-selection and promotion process.
Reassess the design when
- • An isolated old primary cannot be fenced or removed from the write-routing path.
- • Network partitions, witness loss, and asymmetric visibility have not been exercised.
- • Automated failover is enabled without named recovery, rollback, and escalation owners.
- • The platform already provides a different supported PostgreSQL HA control plane.
repmgr standby switchover: evidence gates
A dry run is a useful prerequisite check, not a promise that later execution will succeed. The production plan verifies replication health and WAL, command and SSH permissions, candidate readiness, sibling follow behavior, application routing, load, backups, abort conditions, old-primary rejoin, and post-change correctness.
Before
Confirm topology, lag, WAL, permissions, routes, maintenance scope, backups, dry-run output, and rollback.
During
Observe database state, command results, promotion and demotion, client impact, siblings, and fencing.
After
Validate writes, reads, replication, routing, alerts, backups, former-primary state, and ownership.
JusDB repmgr consulting and implementation
Scope follows the PostgreSQL topology, workload, failure model, recovery objectives, and operating responsibilities. It does not assume automatic failover is appropriate for every cluster.
Architecture and readiness
Map recovery objectives, replication mode, topology, locations, routing, backups, network behavior, and ownership.
Installation and registration
Manage packages, extension, metadata database, users, permissions, primary, standbys, and witness where required.
repmgrd policy
Configure monitoring, reconnect behavior, candidates, priorities, locations, visibility controls, and event hooks.
Fencing and routing
Coordinate infrastructure fencing, proxy or service behavior, draining, retries, stale-primary isolation, and access.
Failure and switchover tests
Exercise process, host, network, witness, replica, routing, and maintenance scenarios with measured outcomes.
DBA handoff
Deliver configuration records, dashboards, alerts, change controls, recovery steps, evidence, and named ownership.
repmgr PostgreSQL replication questions
What is repmgr?
repmgr is an open-source suite for administering PostgreSQL streaming-replication clusters. The repmgr CLI supports node registration, standby cloning, promotion, follow, rejoin, and switchover operations. The optional repmgrd daemon monitors the cluster and can initiate failover when configured. It does not replace backups, routing, fencing, or restore testing.
Does repmgr support automatic failover?
Yes. repmgrd can monitor the primary and initiate failover according to its configuration. Automatic promotion is not a consensus guarantee: network visibility, candidate selection, witness use, primary visibility consensus, fencing, routing, and the old primary's state all matter. We validate the exact topology with host and network failures before enabling it.
What does a repmgr witness server do?
A witness is a PostgreSQL instance that contains a copy of the repmgr metadata records but is not part of the streaming-replication cluster. It can provide an additional point of network visibility for repmgrd decisions. It is not a distributed consensus store and does not remove the need for fencing or partition testing.
How does repmgr handle split-brain risk?
repmgr provides controls such as witness observations, node locations, priorities, primary visibility consensus, event hooks, and daemon settings, but the operator remains responsible for the complete safety design. Reliable fencing and routing must prevent an isolated former primary from serving writes. We test asymmetric partitions and rejoin procedures, not just process failure.
Does repmgr standby switchover guarantee a safe maintenance event?
No command can guarantee every runtime condition. repmgr standby switchover performs prerequisite checks and supports a dry run, but permissions, SSH, replication state, WAL, sibling nodes, application routing, load, and failures can still change. We use a written plan with acceptance, abort, rollback, client-impact, and post-change validation gates.
Can repmgr use Barman?
repmgr can be configured to use a Barman server as a source when cloning a standby, subject to the documented configuration and version compatibility. Barman remains a separate backup and recovery system. Backup retention, WAL availability, restore testing, credentials, network access, and recovery objectives require their own controls.
When should you compare repmgr with Patroni?
Compare them when the coordination model, automation surface, platform integration, and failure semantics affect the operating design. Patroni uses a supported distributed configuration store and exposes REST control interfaces; repmgr keeps its cluster metadata in PostgreSQL and uses CLI plus optional repmgrd. Neither choice removes the need for failure testing and fencing.
Related PostgreSQL DBRE services
Patroni PostgreSQL high availability
Compare Patroni's DCS-backed control loop with the repmgr CLI and repmgrd model.
PostgreSQL high availability
Design replication, failover, routing, backup, recovery, and failure-testing controls.
PostgreSQL support
DBRE-led incident, reliability, upgrade, performance, and operational support.
PostgreSQL services
Review consulting, migration, performance, cloud, security, and reliability services.
repmgr guidance checked against the current project manual
Review scope: PostgreSQL streaming-replication administration, repmgrd monitoring and failover, switchovers, witness behavior, network splits, fencing, rejoin, permissions, and runbook testing. Availability and data-loss exposure remain specific to replication mode, topology, lag, network, fencing, and operator decisions.
Technically reviewed by the JusDB Database Reliability Engineering team. Last reviewed: . See the team and roles.
- repmgr concepts and components
Official scope for repmgr, repmgrd, PostgreSQL streaming replication, witness servers, failover, switchover, and fencing.
- repmgr standby switchover
Primary prerequisites, safety boundaries, dry-run behavior, promotion, demotion, sibling follow, and rejoin guidance.
- repmgrd operation
Official automatic-failover, network-split, witness, consensus, configuration, and monitoring references.
Review your repmgr failure model
Bring the PostgreSQL topology, repmgr configuration, recovery objectives, routing and fencing design, and recent incident evidence. We will scope the safest useful review or implementation.
Contact a database SRE