### Start PostgreSQL Instance

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Starts a PostgreSQL instance using the pg_ctl command. This is a fundamental step before managing the cluster with repmgr. It requires specifying the data directory.

```bash
pg_ctl -D /var/lib/postgresql/16/witness start
```

--------------------------------

### Start repmgrd Service

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Starts the repmgrd daemon in the background. This service is responsible for monitoring and managing replication status, handling failovers, and other background tasks. It requires a repmgr configuration file.

```bash
repmgrd -f /etc/repmgr.conf --daemonize
```

--------------------------------

### Build and Install repmgr with Specific PATH on RedHat

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Builds and installs repmgr using PGXS, ensuring the PostgreSQL binaries are found by prepending the correct directory to the PATH environment variable. This is useful when `pg_config` is not in the default PATH.

```shell
sudo PATH="/usr/pgsql-9.0/bin:$PATH" make USE_PGXS=1 install
```

--------------------------------

### PgBouncer Configuration Example

Source: https://github.com/enterprisedb/repmgr/blob/master/doc/repmgrd-node-fencing.md

This is an example configuration file for PgBouncer. It defines general settings such as log files, listening addresses and ports, authentication methods, and connection pool parameters. It also uses the `%include` directive to incorporate settings from a separate database-specific configuration file, which is intended to be modified dynamically during failover events.

```ini
[pgbouncer]

logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid

listen_addr = *
listen_port = 6532
unix_socket_dir = /tmp

auth_type = trust
auth_file = /etc/pgbouncer.auth

admin_users = postgres
stats_users = postgres

pool_mode = transaction

max_client_conn = 100
default_pool_size = 20
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

log_connections = 1
log_disconnections = 1
log_pooler_errors = 1

%include /etc/pgbouncer.database.ini

```

--------------------------------

### Install PostgreSQL Development Packages on Debian/Ubuntu

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Installs essential development packages for PostgreSQL on Debian-based systems (like Ubuntu). These include libraries for XSLT, XML, PAM, and readline, which are often required for compiling PostgreSQL-related tools.

```shell
sudo apt-get install libxslt-dev libxml2-dev libpam-dev libedit-dev
```

--------------------------------

### Remove and Install Correct PostgreSQL Development Package on RedHat

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Removes all versions of a specific PostgreSQL development package and then installs the correct architecture version. This is a solution for the 'skipping incompatible' linker errors caused by mixed 32-bit and 64-bit package installations.

```shell
rpm -e postgresql90-devel --allmatches
yum install postgresql90-devel-9.0.2-2PGDG.rhel5.x86_64
```

--------------------------------

### Configure Automatic Failover with repmgrd

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Sets up the repmgrd daemon for automatic failover. Includes configuration parameters for node identification, connection details, failover strategy, promotion/follow commands, and monitoring. Also shows how to start, check status, pause, and unpause the daemon.

```bash
# Configuration file: /etc/repmgr.conf
node_id=2
node_name='node2'
conninfo='host=node2.example.com dbname=repmgr user=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/16/main'

# Automatic failover configuration
failover='automatic'
priority=100
promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file'
follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'
connection_check_type='ping'
reconnect_attempts=6
reconnect_interval=10
primary_notification_timeout=60

# Monitoring settings
monitoring_history=yes
monitor_interval_secs=2
log_level='INFO'
log_file='/var/log/postgresql/repmgrd.log'

# Start repmgrd daemon
repmgrd -f /etc/repmgr.conf --daemonize

# Expected log output (/var/log/postgresql/repmgrd.log):
# [2025-10-22 10:00:00] [NOTICE] repmgrd (repmgrd 5.5) starting up
# [2025-10-22 10:00:00] [INFO] connecting to database "host=node2.example.com dbname=repmgr user=repmgr"
# [2025-10-22 10:00:00] [NOTICE] starting monitoring of node "node2" (ID: 2)
# [2025-10-22 10:00:00] [INFO] monitoring connection to upstream node "node1" (ID: 1)
# [2025-10-22 10:00:02] [INFO] node "node2" (ID: 2) monitoring upstream node "node1" (ID: 1) in normal state
# [2025-10-22 10:00:04] [INFO] node "node2" (ID: 2) monitoring upstream node "node1" (ID: 1) in normal state

# Simulated failover scenario:
# [2025-10-22 10:05:15] [WARNING] unable to connect to upstream node "node1" (ID: 1)
# [2025-10-22 10:05:15] [INFO] checking state of node 1, 1 of 6 attempts
# [2025-10-22 10:05:25] [INFO] checking state of node 1, 2 of 6 attempts
# [2025-10-22 10:05:35] [WARNING] unable to reconnect to node 1 after 6 attempts
# [2025-10-22 10:05:35] [NOTICE] this node is the only available candidate and will now promote itself
# [2025-10-22 10:05:35] [INFO] executing "repmgr standby promote -f /etc/repmgr.conf --log-to-file"
# [2025-10-22 10:05:37] [NOTICE] STANDBY PROMOTE successful
# [2025-10-22 10:05:37] [INFO] switching to primary monitoring mode

# Check daemon status
repmgr service status -f /etc/repmgr.conf
# repmgrd is running with PID 12345
# Node "node2" (ID: 2) is running as primary

# Pause daemon during maintenance
repmgr service pause -f /etc/repmgr.conf
# NOTICE: node 2 paused

# Unpause after maintenance
repmgr service unpause -f /etc/repmgr.conf
# NOTICE: node 2 unpaused
```

--------------------------------

### Start and Register Standby after Barman Clone

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Starts the PostgreSQL instance on the newly cloned standby server and then registers it with the repmgr cluster. This completes the process of adding a new standby node that was cloned from a Barman backup.

```bash
pg_ctl -D /var/lib/postgresql/16/main start
repmgr standby register -f /etc/repmgr.conf
```

--------------------------------

### Install PostgreSQL Server Development Package on Debian/Ubuntu

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Installs the specific development package for PostgreSQL server version 9.0 on Debian-based systems. This package is required when building repmgr with the USE_PGXS option and links against the PostgreSQL server libraries.

```shell
sudo apt-get install postgresql-server-dev-9.0
```

--------------------------------

### Register Witness Node with repmgr

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Registers a witness node with the primary PostgreSQL server using the repmgr command. This command connects to the primary, installs the repmgr extension if necessary, and completes the witness registration. It requires a configuration file and connection details for the primary.

```bash
repmgr witness register -f /etc/repmgr.conf -h node1.example.com -U repmgr -d repmgr
```

--------------------------------

### Install PostgreSQL Development Packages on RedHat

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Installs necessary development packages for PostgreSQL on RedHat-based systems (like CentOS and Fedora) to resolve build errors. These packages provide headers and libraries required to compile software that links against PostgreSQL.

```shell
yum install libxslt-devel
yum install pam-devel
```

--------------------------------

### Check for Conflicting PostgreSQL Development Packages on RedHat

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Queries the system to list installed PostgreSQL development packages and their architectures. This helps identify and resolve issues caused by having both 32-bit and 64-bit versions of the same development package installed simultaneously.

```shell
rpm -qa --queryformat '%{NAME}\t%{ARCH}\n'  | grep postgresql90-devel
```

--------------------------------

### Register repmgr Binaries with update-alternatives on Debian/Ubuntu

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Registers the repmgr and repmgrd executable binaries with the Debian alternatives system. This makes the commands available system-wide and manageable through the alternatives mechanism, even though they are installed in a non-standard path.

```shell
sudo update-alternatives --install /usr/bin/repmgr repmgr /usr/lib/postgresql/9.0/bin/repmgr 10
sudo update-alternatives --install /usr/bin/repmgrd repmgrd /usr/lib/postgresql/9.0/bin/repmgrd 10
```

--------------------------------

### Clean repmgr Build on RedHat

Source: https://github.com/enterprisedb/repmgr/blob/master/PACKAGES.md

Cleans leftover build artifacts from a previous repmgr compilation on RedHat systems. This is necessary after resolving issues like mixed architecture package installations before attempting to rebuild.

```shell
make USE_PGXS=1 clean
```

--------------------------------

### Register Primary Node with repmgr CLI

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Initializes a repmgr cluster and registers the primary PostgreSQL server. Requires a configuration file defining node details and connection information. Outputs confirmation upon successful registration.

```bash
# Initialize repmgr cluster and register primary node
repmgr -f /etc/repmgr.conf primary register

# Configuration file: /etc/repmgr.conf
node_id=1
node_name='node1'
conninfo='host=node1.example.com dbname=repmgr user=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/16/main'
replication_user='repmgr'
use_replication_slots=yes

# Expected output:
# NOTICE: attempting to install extension "repmgr"
# NOTICE: "repmgr" extension successfully installed
# INFO: connecting to primary database...
# NOTICE: primary node record (ID: 1) registered

# Verify registration
repmgr cluster show
# ID | Name  | Role    | Status    | Upstream | Location | Priority | Timeline | Connection string
# ---|-------|---------|-----------|----------|----------|----------|----------|-----------------
#  1 | node1 | primary | * running |          | default  | 100      | 1        | host=node1.example.com...
```

--------------------------------

### Configure Witness Server for Failover Consensus

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Details the configuration of a witness server for repmgr, which participates in failover consensus without storing data. Includes basic configuration parameters and the initialization of a lightweight PostgreSQL instance.

```bash
# Configuration file: /etc/repmgr.conf (on witness server)
node_id=4
node_name='witness1'
conninfo='host=witness1.example.com dbname=repmgr user=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/16/witness'
witness_sync_interval=15

# Initialize witness database (small PostgreSQL instance)
initdb -D /var/lib/postgresql/16/witness
```

--------------------------------

### Create repmgr Database and User

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Creates a dedicated superuser and database for repmgr. This user and database are essential for repmgr to manage replication and other cluster operations. Requires access to the PostgreSQL server.

```bash
psql -p 5432 postgres -c "CREATE USER repmgr SUPERUSER"
psql -p 5432 postgres -c "CREATE DATABASE repmgr OWNER repmgr"
```

--------------------------------

### Clone Standby Server using repmgr and pg_basebackup

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Clones a standby PostgreSQL server from a primary or upstream node using pg_basebackup. This command facilitates setting up new replication nodes and requires a configuration file on the standby. It includes options for fast checkpointing and copying external configuration files.

```bash
# Clone standby from primary with replication slots enabled
repmgr -h node1.example.com -U repmgr -d repmgr \
  standby clone -f /etc/repmgr.conf \
  --fast-checkpoint \
  --copy-external-config-files=/etc/postgresql

# Configuration file: /etc/repmgr.conf (on standby)
node_id=2
node_name='node2'
conninfo='host=node2.example.com dbname=repmgr user=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/16/main'
replication_user='repmgr'
use_replication_slots=yes

# Expected output:
# NOTICE: destination directory "/var/lib/postgresql/16/main" provided
# INFO: connecting to source node
# NOTICE: checking for available walsenders on the source node (2 required)
# INFO: sufficient walsenders available on the source node
# INFO: creating replication slot "repmgr_slot_2"
# NOTICE: starting backup (using pg_basebackup)...
# INFO: executing: pg_basebackup -l "repmgr base backup" -D /var/lib/postgresql/16/main -h node1.example.com...
# NOTICE: standby clone (using pg_basebackup) complete
# NOTICE: you can now start your PostgreSQL server

# Start PostgreSQL and register standby
pg_ctlcluster 16 main start
repmgr -f /etc/repmgr.conf standby register
# INFO: standby node "node2" (ID: 2) successfully registered
```

--------------------------------

### Clone Standby from Barman Backup

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Clones a new standby PostgreSQL server from a Barman backup instead of directly from a primary. This method is useful for setting up new replicas or recovering existing ones using a point-in-time recovery from Barman. It requires Barman integration settings in the repmgr configuration and upstream node details.

```bash
repmgr -h node1.example.com -U repmgr -d repmgr \
  standby clone -f /etc/repmgr.conf \
  --upstream-node-id=1
```

--------------------------------

### PostgreSQL repmgrd Promote Script with PgBouncer Reconfiguration

Source: https://github.com/enterprisedb/repmgr/blob/master/doc/repmgrd-node-fencing.md

This bash script is designed to be used as the `promote_command` in repmgrd. It first promotes a standby node to primary using `repmgr standby promote` and then reconfigures PgBouncer instances on specified hosts. It dynamically generates a new PgBouncer database configuration file by querying the repmgr.nodes table for primary and standby connection information. Finally, it uses rsync to copy the updated configuration and reloads PgBouncer on each host. Requires password-less SSH access and write permissions for the postgres user to PgBouncer configuration files.

```bash
#!/usr/bin/env bash
set -u
set -e

# Configurable items
PGBOUNCER_HOSTS="node1 node2 node3"
PGBOUNCER_DATABASE_INI="/etc/pgbouncer.database.ini"
PGBOUNCER_DATABASE="appdb"
PGBOUNCER_PORT=6432

REPMGR_DB="repmgr"
REPMGR_USER="repmgr"

# 1. Promote this node from standby to primary

repmgr standby promote -f /etc/repmgr.conf --log-to-file

# 2. Reconfigure pgbouncer instances

PGBOUNCER_DATABASE_INI_NEW="/tmp/pgbouncer.database.ini"

for HOST in $PGBOUNCER_HOSTS
d
o
    # Recreate the pgbouncer config file
    echo -e "[databases]\n" > $PGBOUNCER_DATABASE_INI_NEW

    psql -d $REPMGR_DB -U $REPMGR_USER -t -A \
      -c "SELECT '${PGBOUNCER_DATABASE}-rw= ' || conninfo || ' application_name=pgbouncer_${HOST}' \
          FROM repmgr.nodes \
          WHERE active = TRUE AND type='primary'" >> $PGBOUNCER_DATABASE_INI_NEW

    psql -d $REPMGR_DB -U $REPMGR_USER -t -A \
      -c "SELECT '${PGBOUNCER_DATABASE}-ro= ' || conninfo || ' application_name=pgbouncer_${HOST}' \
          FROM repmgr.nodes \
          WHERE node_name='${HOST}'" >> $PGBOUNCER_DATABASE_INI_NEW


    rsync $PGBOUNCER_DATABASE_INI_NEW $HOST:$PGBOUNCER_DATABASE_INI

    psql -tc "reload" -h $HOST -p $PGBOUNCER_PORT -U postgres pgbouncer

done

# Clean up generated file
rm $PGBOUNCER_DATABASE_INI_NEW

echo "Reconfiguration of pgbouncer complete"

```

--------------------------------

### Show repmgr Cluster Connectivity Matrix

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Displays a connectivity matrix showing which nodes can connect to other nodes in the cluster. It includes commands to show connectivity from a single node's perspective and from all nodes' perspectives.

```bash
repmgr cluster matrix -f /etc/repmgr.conf
```

```bash
repmgr cluster crosscheck -f /etc/repmgr.conf
```

--------------------------------

### Query repmgr Cluster Events

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Demonstrates how to query repmgr cluster event logs. Supports filtering by event type, node name, and exporting output in CSV format. Useful for monitoring cluster activity and troubleshooting.

```bash
# Filter by event type
repmgr cluster event --event=standby_switchover --limit=5
#  Node ID | Name  | Event              | OK | Timestamp           | Details
# ---------+-------+--------------------+----+---------------------+----------------------------------
#  2       | node2 | standby_switchover | t  | 2025-10-22 10:30:15 | node "node2" promoted to primary

# Filter by node
repmgr cluster event --node-name=node2 --limit=10
#  Node ID | Name  | Event              | OK | Timestamp           | Details
# ---------+-------+--------------------+----+---------------------+----------------------------------
#  2       | node2 | standby_switchover | t  | 2025-10-22 10:30:15 | node "node2" promoted to primary
#  2       | node2 | standby_promote    | t  | 2025-10-22 08:45:23 | node "node2" promoted to primary
#  2       | node2 | standby_register   | t  | 2025-10-21 14:20:05 | standby registered

# Export events as CSV
repmgr cluster event --csv --limit=50
# Node ID,Node name,Event,OK,Timestamp,Details
# 2,node2,standby_switchover,t,"2025-10-22 10:30:15","node ""node2"" (ID: 2) promoted to primary"
# 1,node1,repmgrd_start,t,"2025-10-22 09:15:42","monitoring connection established"
```

--------------------------------

### Promote Standby to Primary with repmgr

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Promotes a standby PostgreSQL server to become the new primary, typically during a failover. This command can also notify sibling nodes to follow the newly promoted primary. It includes options to control behavior during promotion, such as sibling following.

```bash
# Promote standby to primary with sibling follow
repmgr standby promote -f /etc/repmgr.conf --siblings-follow

# Expected output:
# NOTICE: promoting standby to primary
# DETAIL: promoting server "node2" (ID: 2) using pg_promote()
# NOTICE: waiting up to 60 seconds (parameter "promote_check_timeout") for promotion to complete
# INFO: standby promoted to primary after 2 second(s)
# NOTICE: STANDBY PROMOTE successful
# DETAIL: server "node2" (ID: 2) was successfully promoted to primary
# INFO: 1 sibling nodes to notify
# NOTICE: notifying node "node3" (ID: 3) to follow node 2
# INFO: node 3 received notification to follow node 2

# Verify new cluster state
repmgr cluster show
# ID | Name  | Role    | Status    | Upstream | Location | Priority | Timeline | Connection string
# ---|-------|---------|-----------|----------|----------|----------|----------|-----------------
#  2 | node2 | primary | * running |          | default  | 100      | 2        | host=node2.example.com...
#  3 | node3 | standby |   running | node2    | default  | 100      | 2        | host=node3.example.com...
```

--------------------------------

### Configure Standby to Follow New Primary

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Redirects a standby PostgreSQL server to replicate from a new primary node after a promotion or topology change. This command uses repmgr's configuration file and the upstream node ID to establish the new replication relationship. It includes steps for verification.

```bash
# Configure standby to follow new primary (node 2)
repmgr standby follow -f /etc/repmgr.conf --upstream-node-id=2 --verbose

# Expected output:
# NOTICE: setting node 3's upstream to node 2
# INFO: changing standby's upstream node to node 2
# NOTICE: reloading configuration
# INFO: prerequisites for using pg_rewind are met
# INFO: stopping server using pg_ctl
# INFO: waiting for server to shut down...
# INFO: server stopped successfully
# NOTICE: running pg_rewind on standby
# INFO: executing pg_rewind
# NOTICE: restarting server
# INFO: server restarted successfully
# NOTICE: node "node3" (ID: 3) now following new upstream node "node2" (ID: 2)
# DETAIL: node 3 is replicating from node 2

# Verify replication status
repmgr node status --verbose
# Node "node3":
#   PostgreSQL version: 16.0
#   Role: standby
#   Upstream node: node2 (ID: 2)
#   Replication lag: 0 bytes
#   Last received LSN: 0/5000000
#   Last replayed LSN: 0/5000000
#   Replication state: streaming
```

--------------------------------

### Query repmgr Monitoring History using SQL

Source: https://context7.com/enterprisedb/repmgr/llms.txt

This SQL query fetches historical monitoring data for standby nodes, specifically focusing on replication lag and apply lag at different points in time. It requires the repmgr extension's monitoring_history to be enabled. The results are ordered by the last monitor time and limited to the most recent entries for a specific standby node.

```sql
-- Query monitoring history (if monitoring_history enabled)
SELECT standby_node_id, last_monitor_time, replication_lag, apply_lag
FROM repmgr.monitoring_history
WHERE standby_node_id = 2
ORDER BY last_monitor_time DESC
LIMIT 5;
```

--------------------------------

### Verify Cluster Status with repmgr

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Displays the current status of the PostgreSQL cluster managed by repmgr. This command shows details about all nodes, their roles, status, and replication connections. Useful for verifying cluster health.

```bash
repmgr cluster show
```

--------------------------------

### Query repmgr Node Metadata using SQL

Source: https://context7.com/enterprisedb/repmgr/llms.txt

This SQL query retrieves essential metadata for each node in the repmgr cluster, including its ID, name, type (primary/standby), upstream node, priority, and active status. It requires connecting to the repmgr database using the psql client.

```sql
psql -U repmgr repmgr

-- Query node metadata
SELECT node_id, node_name, type, upstream_node_id, priority, active
FROM repmgr.nodes
ORDER BY node_id;
```

--------------------------------

### Control repmgrd Daemon with SQL Functions

Source: https://context7.com/enterprisedb/repmgr/llms.txt

This SQL demonstrates how to manually control the repmgrd daemon's pause state using the repmgr extension functions. `repmgr.repmgrd_pause(true)` will pause the daemon, stopping its monitoring and failover operations, while `repmgr.repmgrd_pause(false)` will resume its normal operation. This requires appropriate permissions.

```sql
-- Manually pause/unpause repmgrd from SQL
SELECT repmgr.repmgrd_pause(true);  -- pause
SELECT repmgr.repmgrd_pause(false); -- unpause
```

--------------------------------

### Retrieve repmgr Event History

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Queries the repmgr event log to review cluster management actions and their outcomes. The command can display a specified number of recent events.

```bash
repmgr cluster event -f /etc/repmgr.conf
```

--------------------------------

### Display repmgr Cluster Status

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Displays comprehensive status information for all nodes in a replication cluster. It supports detailed output, compact output without connection strings, and CSV export.

```bash
repmgr cluster show -f /etc/repmgr.conf
```

```bash
repmgr cluster show --compact
```

```bash
repmgr cluster show --csv
```

--------------------------------

### Perform Planned Switchover Operation

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Executes a coordinated switchover of the primary role from the current primary to a specified standby server, ensuring zero data loss. This operation can automatically handle sibling node replication and uses force-rewind if necessary. The command concludes with cluster status verification.

```bash
# Switchover from node1 (primary) to node2 (standby) with automatic sibling follow
repmgr standby switchover -f /etc/repmgr.conf \
  --siblings-follow \
  --force-rewind \
  --verbose

# Expected output:
# NOTICE: executing switchover on node "node2" (ID: 2)
# INFO: SSH connection to host "node1.example.com" succeeded
# INFO: able to execute on remote host "node1.example.com"
# INFO: all sibling nodes are reachable via SSH
# NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
# INFO: 5432 on node 1 is available, checking replication lag
# NOTICE: replication lag on this standby is 0 seconds
# NOTICE: attempting to pause repmgrd on 3 nodes
# INFO: node 1 (node1): paused repmgrd
# INFO: node 2 (node2): paused repmgrd
# INFO: node 3 (node3): paused repmgrd
# NOTICE: shutting down current primary node "node1" (ID: 1)
# INFO: current primary has been cleanly shut down at location 0/6000000
# NOTICE: promoting standby to primary
# DETAIL: promoting server "node2" (ID: 2) using pg_promote()
# NOTICE: STANDBY PROMOTE successful
# DETAIL: server "node2" (ID: 2) was successfully promoted to primary
# INFO: local node 2 promoted to primary
# INFO: node 1 is pingable
# INFO: sleeping 2 seconds until demoted primary has shut down
# NOTICE: setting node 1's upstream to node 2
# INFO: running pg_rewind on old primary server
# NOTICE: restarting server on node "node1" (ID: 1)
# INFO: node "node1" is reachable via SSH
# NOTICE: node "node1" (ID: 1) is now following node "node2" (ID: 2)
# INFO: notifying node "node3" (ID: 3) to follow new primary node 2
# NOTICE: attempting to unpause repmgrd on 3 nodes
# NOTICE: SWITCHOVER SUCCESSFUL

repmgr cluster show
# ID | Name  | Role    | Status    | Upstream | Location | Priority | Timeline | Connection string
# ---|-------|---------|-----------|----------|----------|----------|----------|-----------------
#  2 | node2 | primary | * running |          | default  | 100      | 2        | host=node2.example.com...
#  1 | node1 | standby |   running | node2    | default  | 100      | 2        | host=node1.example.com...
#  3 | node3 | standby |   running | node2    | default  | 100      | 2        | host=node3.example.com...
```

--------------------------------

### Check repmgrd Daemon Status with SQL Functions

Source: https://context7.com/enterprisedb/repmgr/llms.txt

These SQL queries utilize repmgr extension functions to check the operational status of the repmgrd daemon. `repmgrd_is_running()` returns a boolean indicating if the daemon is active, and `repmgrd_is_paused()` indicates if it's currently in a paused state. These functions help in quick status checks directly from SQL.

```sql
-- Check repmgrd status using extension function
SELECT repmgr.repmgrd_is_running();

-- Check if repmgrd is paused
SELECT repmgr.repmgrd_is_paused();
```

--------------------------------

### View repmgr Event History using SQL

Source: https://context7.com/enterprisedb/repmgr/llms.txt

This SQL query allows you to view a log of recent events recorded by repmgr. It displays the node ID, event type, success status, timestamp, and details for each event, ordered by timestamp in descending order, limited to the last 10 events. This is useful for auditing and troubleshooting.

```sql
-- View recent events
SELECT node_id, event, successful, event_timestamp, details
FROM repmgr.events
ORDER BY event_timestamp DESC
LIMIT 10;
```

--------------------------------

### Check repmgr Replication Status using SQL

Source: https://context7.com/enterprisedb/repmgr/llms.txt

This SQL query provides a detailed view of the replication status between primary and standby nodes. It includes information such as the primary and standby node IDs, the standby's name, node type, active status, the last time monitoring occurred, and various replication lag metrics. This helps in identifying replication delays.

```sql
-- Check current replication status
SELECT * FROM repmgr.replication_status;
```

--------------------------------

### Check Last Standby Promotion Event

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Retrieves the most recent standby promotion event from the repmgr cluster event history. Useful for auditing or understanding recent topology changes. It limits the output to the single latest event.

```bash
# Check promotion event in history
repmgr cluster event --event=standby_promote --limit=1
# Node ID | Name  | Event           | OK | Timestamp           | Details
# --------|-------|-----------------|----|--------------------|----------
#  2      | node2 | standby_promote | t  | 2025-10-22 10:15:32 | node "node2" (ID: 2) promoted to primary
```

--------------------------------

### Retrieve repmgrd Process ID using SQL Function

Source: https://context7.com/enterprisedb/repmgr/llms.txt

This SQL query uses the `repmgr.get_repmgrd_pid()` function provided by the repmgr extension to retrieve the Process ID (PID) of the running repmgrd daemon. This can be useful for system-level monitoring or debugging purposes.

```sql
-- Get repmgrd PID
SELECT repmgr.get_repmgrd_pid();
```

--------------------------------

### Rejoin repmgr Node After Failure

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Rejoins a failed or diverged node back into the replication cluster using pg_rewind. This process requires specific configuration prerequisites and can be forced with options like `--force-rewind` and `--verbose`. After rejoining, the node status should be verified.

```bash
repmgr node rejoin -f /etc/repmgr.conf \
  --force-rewind \
  --config-files=postgresql.conf,postgresql.auto.conf,pg_hba.conf \
  --verbose
```

```bash
repmgr node status
```

--------------------------------

### Perform Comprehensive Node Health Check

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Conducts a series of health checks on a PostgreSQL node from a replication perspective, verifying its role, replication lag, WAL archiving status, downstream connections, replication slots, data directory configuration, and repmgrd service status. It also supports specific checks and Nagios-compatible output.

```bash
# Execute all health checks
repmgr node check -f /etc/repmgr.conf

# Expected output:
# Node "node2":
#   Server role:                  OK (node is primary)
#   Replication lag:              OK (N/A - node is primary)
#   WAL archiving:                OK (0 WAL files ready for archiving)
#   Downstream servers:           OK (2 of 2 downstream nodes attached)
#   Replication slots:            OK (node has 2 physical replication slots; 0 missing)
#   Missing physical slots:       OK (node has all expected physical replication slots)
#   Configured data directory:    OK (configured "data_directory" is "/var/lib/postgresql/16/main")
#   repmgrd:                      OK (running with PID 12345)

# Check specific aspect with Nagios-compatible output
repmgr node check --replication-lag --nagios
# REPMGR_REPLICATION_LAG OK: replication lag is 0 seconds | lag=0;300;600

# Check downstream nodes are connected
repmgr node check --downstream
# OK (2 of 2 downstream nodes attached)
```

--------------------------------

### Check repmgr Node Slots Status

Source: https://context7.com/enterprisedb/repmgr/llms.txt

Checks the status of replication slots on a repmgr node. It can report if all physical replication slots are active. The output can also be exported in CSV format for further analysis.

```bash
repmgr node check --slots
```

```bash
repmgr node check --csv
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.