Lightweight PostgreSQL Replication
When Patroni Is Overkill — repmgr Delivers PostgreSQL HA Without the Complexity
repmgr is an open-source suite of tools for managing PostgreSQL streaming replication and automated failover. Storing cluster metadata inside PostgreSQL itself, it operates without external distributed consensus stores like etcd or Consul. The repmgrd daemon automates standby promotion and node fencing, while native Barman integration streamlines standby cloning and disaster recovery.
repmgr manages PostgreSQL streaming replication and standby promotion with zero dependency on etcd, Consul, or Kubernetes. It is the right tool for teams that want reliable PostgreSQL replication without running a distributed coordination cluster.
How repmgr Works
repmgr is a PostgreSQL extension and CLI toolset from 2ndQuadrant (now EDB). It registers primary and standby nodes, manages replication slots, clones standbys, and — via the optional repmgrd daemon — performs automatic failover when a primary becomes unreachable.
No External DCS
repmgr stores cluster state inside PostgreSQL itself — no etcd, Consul, or ZooKeeper cluster to run and maintain. Ideal for simpler environments.
repmgrd Auto Failover
The repmgrd daemon monitors the primary. On failure, it promotes the most up-to-date standby and notifies other nodes to follow the new primary.
Barman Integration
First-class integration with Barman for physical backups. repmgr can clone standbys directly from a Barman backup, reducing load on the primary during standby setup.
Cascading Replication
Register standbys that replicate from other standbys rather than the primary — useful for geographically distributed read replicas without overloading primary bandwidth.
Simple CLI Operations
repmgr standby switchover, repmgr standby clone, repmgr cluster show — a small set of commands that are easy for DBAs to learn and use in runbooks.
Upgrade-Safe Architecture
repmgr uses PostgreSQL's own replication protocol with no wrapping layer, making it straightforward to upgrade PostgreSQL versions without tool-specific complications.
Resilience Engineering
repmgr Production Failure Modes
Critical streaming replication and failover failure scenarios analyzed and remediated by JusDB DBREs to prevent dual-primary writes during network splits, timeline desynchronization, and witness false alarms.
Split-Brain Dual-Primary Promotion via Asymmetric Network Partition
During partial network partitions where standbys lose connectivity to the primary but can still reach each other or a stale witness node, repmgrd can initiate election and promote a standby while the original primary continues accepting application writes.
Configure strict primary_visibility_consensus, deploy repmgr witness nodes in an independent network zone, and implement STONITH or network isolation fencing scripts triggered immediately upon election.
Replication Slot Desynchronization and Timeline ID Divergence
When a promoted standby assumes a new timeline ID without repmgr node rejoin or pg_rewind synchronization, surviving standby nodes fail to follow the new primary and replication halts, risking total standby detachment.
Automate post-promotion follow hooks with pg_rewind integration, enforce wal_keep_size headroom, and execute automated repmgr node rejoin verification in the failover script.
Witness Node Stale Quorum and False Promotion Triggers
A single repmgr witness node running on degraded or resource-constrained hardware can report false failure metrics or timeout during transient load, causing repmgrd to miscalculate quorum and trigger unneeded election cycles.
Provision witness nodes with dedicated NTP clock synchronization, monitor witness heartbeat latency, and configure location-aware weighting with reconnect_attempts tuning.
Cluster Telemetry
Production repmgr Diagnostic Runbooks
Non-blocking inspection commands executed via the repmgr CLI and PostgreSQL system views to audit cluster member health, upstream WAL streaming lag, and switchover readiness.
Audits live member status, upstream connection health, timeline IDs, and standby WAL byte lag across primary and replica nodes.
# Verify live cluster topology, timeline progression, and node roles repmgr -f /etc/repmgr.conf cluster show # Query upstream connection status and replication lag directly repmgr -f /etc/repmgr.conf node check --role=primary repmgr -f /etc/repmgr.conf node check --role=standby # Inspect replication event history stored in PostgreSQL repmgr schema psql -U repmgr -d repmgr -c "SELECT event_timestamp, event, successful, details FROM repmgr.events ORDER BY event_timestamp DESC LIMIT 10;"
Inspects repmgrd monitoring processes, election timeouts, and dry-run switchover feasibility to ensure clean maintenance windows.
# Verify repmgrd daemon status and active monitoring threads repmgr -f /etc/repmgr.conf cluster status # Perform a dry-run check of manual standby switchover readiness repmgr -f /etc/repmgr.conf standby switchover --dry-run # Inspect active PostgreSQL replication slots and unconsumed WAL bytes psql -U postgres -c "SELECT slot_name, plugin, active, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag_bytes FROM pg_replication_slots;"
repmgr vs Patroni vs Cloud HA vs Scripted
Both repmgr and Patroni manage PostgreSQL replication and failover, but their architectures are fundamentally different. Compare operational complexity, quorum safety, and DCS footprint side-by-side.
| 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 sub-30s planned maintenance and zero topology drift | 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 |
| 24/7 Production DBRE & Sub-15m P1 SLA | Continuous repmgr node event auditing, replication slot lag alerting, senior DBRE on-call 24/7, and contractual <15m P1 response | 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 |
When repmgr Beats Patroni
Ideal scenarios for repmgr
- • PostgreSQL on VMs or bare-metal (not Kubernetes)
- • Team unfamiliar with etcd/Consul distributed systems
- • You already use Barman for backup — repmgr integrates natively
- • Manual or semi-automated failover is acceptable for your SLA
- • Small-to-medium scale (1 primary + 1–3 standbys)
- • You want to avoid the operational overhead of a DCS cluster
- • EDB subscription or support contract already in place
Upgrade to Patroni when…
- • You move PostgreSQL to Kubernetes
- • You need sub-30-second automatic failover with strong consistency guarantees
- • You need REST API integration with infrastructure automation
- • Multi-DC or multi-region HA with consensus-based leader election
- • You use Zalando Operator, Crunchy PGO, or CloudNativePG
JusDB repmgr Implementation Service
We set up and operate repmgr clusters with full documentation, monitoring, and tested failover runbooks.
Cluster Installation & Registration
Install repmgr extension, configure repmgr.conf, register primary and all standby nodes with the repmgr metadata database.
repmgrd Auto-failover Setup
Deploy and configure the repmgrd daemon, tune failover thresholds (reconnect_attempts, reconnect_interval), and test promotion scenarios.
Barman Backup Integration
Configure repmgr to use Barman as the clone source for new standbys, reducing load on primary during clone operations and enabling PITR from Barman backups.
Cascading Standby Configuration
Set up multi-tier replication for geographically distributed read replicas with proper upstream standby configuration.
Switchover Runbooks
Document and test planned switchover procedures (repmgr standby switchover) for zero-downtime maintenance windows.
Monitoring & Alerting
repmgr cluster show integrated into monitoring pipelines, alerting on replication lag, standby disconnection, and repmgrd health.
repmgr PostgreSQL Replication: Frequently Asked Questions
Set up repmgr the right way
JusDB implements and operates repmgr clusters with tested failover procedures and 24/7 monitoring — so you can focus on your application.