1

Implementing PostgreSQL Replication and Failover Solutions Using repmgr

Objective: To enhance database reliability, performance, and management through

PostgreSQL replication and failover.

Key Benefits:

● High Availability:
○ Goal: Minimize downtime and maintain continuous database availability.
○ How: By replicating data from a primary server to standby servers, ensuring
service continuity even during server failures.
● Data Redundancy:
○ Goal: Protect against data loss and ensure data integrity.
○ How: Real-time replication to standby servers provides an up-to-date backup,
crucial for disaster recovery.
● Automatic Failover:
○ Goal: Ensure seamless transition in case of primary server failure.
○ How: repmgr facilitates automatic failover, promoting standby servers to primary
status without manual intervention.
● Scalability:
○ Goal: Optimize database performance and handle increasing workloads.
○ How: Distributes read queries and load across multiple servers, enhancing overall
system performance.
● Backup and Recovery:
○ Goal: Improve backup efficiency and recovery processes.
○ How: Standby servers can be utilized for backups, reducing the impact on the
primary server and ensuring quick recovery.

Overall Impact: Implementing PostgreSQL replication and failover with repmgr delivers robust
data protection, high availability, and streamlined database management, positioning your
organization to effectively handle database challenges and growth.
 2

On the Primary Server:

1. Install PostgreSQL 14 RPM:

2. Install repmgr 14:

● Install repmgr using RPM:

sudo dnf install -y repmgr_14*

3. Configure PostgreSQL for Replication:

● Edit $PGDATA/postgresql.conf

vim $PGDATA/postgresql.conf

Add or update the following parameters:

listen_addresses = '*'

wal_level = replica

max_wal_senders = 10
 3

max_replication_slots = 10

wal_keep_size = 1GB

hot_standby = on

shared_preload_libraries = 'repmgr'

Save and exit.

The shared_preload_libraries setting in PostgreSQL is used to load certain libraries at server

startup. When you set shared_preload_libraries = 'repmgr', it tells PostgreSQL to preload the
repmgr extension, which is necessary for repmgr to function correctly.

Here's why you need this setting:

● Replication Management: repmgr is a tool used for managing replication and failover in
PostgreSQL. For repmgr to integrate with PostgreSQL and manage replication
effectively, it needs to be loaded as a shared library when PostgreSQL starts.
● Extended Functionality: Loading repmgr as a shared library allows it to extend
PostgreSQL’s capabilities with additional functionality required for replication and
failover operations.
● Configuration and Monitoring: The repmgr extension allows you to configure and
monitor replication from within PostgreSQL, and it needs to be available as soon as
PostgreSQL starts to manage these tasks properly.

To apply this change, you need to update the PostgreSQL configuration file (postgresql.conf),
add repmgr to the shared_preload_libraries list, and then restart the PostgreSQL server for the
changes to take effect.

4. Restart and Check PostgreSQL Services:

systemctl restart postgresql-14.service

systemctl status postgresql-14.service

5. Create User and Database for repmgr:

 4

6. Configure Connectivity for repmgr User:

● Edit $PGDATA/pg_hba.conf:

vim $PGDATA/pg_hba.conf

Add the following entries:

Save and exit.

● Reload PostgreSQL configurations:

SELECT pg_reload_conf();

● Check connectivity:
 5

su - postgres -c "psql -d repmgr -U repmgr -h 192.168.0.103"

7. Edit repmgr Configuration on Primary Server:

● Edit /etc/repmgr/14/repmgr.conf:

vim /etc/repmgr/14/repmgr.conf

Add the following entries:

Save and exit.

8. Register the Primary Server with repmgr:

● Check the cluster status:

On the Standby Server:

9. Install PostgreSQL & Repmgr As Above:

 6

10. Edit repmgr Configuration on Standby Server:

● Edit /etc/repmgr/14/repmgr.conf:

vim /etc/repmgr/14/repmgr.conf

Add the following entries:

Save and exit.

11. Perform a Dry Run for Configuration Validation:

The error indicates that the target data directory /var/lib/pgsql/14/data appears to contain a
running PostgreSQL instance. Here’s what you can do to resolve this issue:

● Check if PostgreSQL is Running: Ensure that there is no active PostgreSQL instance

using the target data directory. You can check the status of PostgreSQL with:

sudo systemctl start postgresql-14.service

● Verify the Data Directory: Make sure that the data directory specified is indeed the
correct one and not being used by another PostgreSQL instance. You can verify the
directory with:

sudo -u postgres psql -c "SHOW data_directory;"

 7

● Stop PostgreSQL: If PostgreSQL is running and using the data directory, stop the
PostgreSQL service before proceeding with the repmgr clone operation:

sudo systemctl stop postgresql-14.service

● Verify the Directory Status: Since the dry-run didn’t show any issues with connecting
or prerequisites, you should ensure that overwriting the existing data directory is the right
step. Double-check that the /var/lib/pgsql/14/data directory should be overwritten and is
not currently in use.
● Proceed with Cloning (if appropriate): If you’re sure that overwriting the directory is
correct, re-run the repmgr clone command with the -F/--force option:

● Start PostgreSQL: Start the PostgreSQL service after proceeding with the repmgr clone
operation:

sudo systemctl start postgresql-14.service

● Monitor the Process: After running the command, monitor the PostgreSQL logs and the
replication process to ensure that the standby setup proceeds as expected.
 8

● Post-Setup Verification: After the cloning process completes, verify the standby server's
status and ensure that it has correctly attached to the primary node. You can check this
with:

Here’s what you can do to properly register the standby node:

● Start the Standby Node (if not already started):

sudo systemctl start postgresql-14.service

● Register the Standby Node: Run the following command on the standby node to
register it with the primary node in the repmgr cluster.

sudo -u postgres /usr/pgsql-14/bin/repmgr -f /etc/repmgr/14/repmgr.conf standby register

This command registers the standby node with the primary node in the replication cluster.

● Verify Registration: After registering, verify the cluster's status by running the
following command on either node:

sudo -u postgres /usr/pgsql-14/bin/repmgr -f /etc/repmgr/14/repmgr.conf cluster show

"Note: If you don’t want to clone into the default directory with overwrite, you can delete
the old directory and run the cloning process again without using the force option."

● Navigate to the data directory:

cd /var/lib/pgsql/14/data/

● Delete the contents of the directory:

rm -rf *

● Run the dry-run of the standby clone:

sudo -u postgres /usr/pgsql-14/bin/repmgr -h 192.168.0.103 -U repmgr -d repmgr -f

/etc/repmgr/14/repmgr.conf standby clone --dry-run

● Run the actual standby clone:

 9

sudo -u postgres /usr/pgsql-14/bin/repmgr -h 192.168.0.103 -U repmgr -d repmgr -f

/etc/repmgr/14/repmgr.conf standby clone
 10

12. Register the Standby Node with repmgr:

● Check the cluster status:

13. Verify Replication:

 11

● On Primary Server:

SELECT * FROM pg_stat_replication;

● Create a database:

CREATE DATABASE testing;

● Connect to the new database:

\c testing

● Create a table:
● Insert records into the table:
 12

● Check that the records are inserted:

● On the Standby Node:

To verify replication, connect to the standby node and check if the changes made on the primary
are replicated:

● Connect to the standby node:

● Check if the table and records exist:

1. Check if the standby is in recovery mode:

 13

If it returns true, the server is in standby mode.