Postgresql Replication

PostgreSQL replication copies data from one server to another in real time, ensuring data is always available, even during server failures. This helps with data security.

In this article, we will explain PostgreSQL Replication in detail with examples and its benefits.

PostgreSQL Replication

• PostgreSQL replication is a method of copying data from one database server to another server in real-time.
  
• This process ensures data security and availability.
  
• It helps to maintain smooth system operation even during server failures.
  
• It is used for tasks such as data backup, handling server failures, and load balancing between servers.

What Is Automatic Failover?

Automatic failover is when a backup server automatically takes over if the main server stops working. This helps keep the system running smoothly with little downtime, preventing data loss and service interruptions.

Benefits of Using PostgreSQL Replication

• Data Availability: Data is continuously copied to a replica and make sure it is always available.
  
• Load Balancing: Replicas can handle read queries, allowing the primary server to manage only write operations.
  
• Fault Tolerance: In case of a primary server failure, a replica can take over, ensuring continuous service.

Types of PostgreSQL Replication

1. Streaming Replication

Streaming replication sends Write-Ahead Log (WAL) records from the primary server to the replica in real-time, keeping data consistent. The replica operates in read-only mode, allowing to scale the database for read-heavy workloads.

2. Logical Replication

Logical replication allows replicating specific tables instead of the whole database. It is flexible and suitable for selective replication, schema migrations, or data transformations.

3. Synchronous and Asynchronous Replication

• Synchronous Replication: The primary server waits for the replica to acknowledge the transaction before committing. This ensures zero data loss at the cost of increased latency.
  
• Asynchronous Replication: The primary server doesn’t wait for acknowledgment from the replica. This is faster but can result in minimal data loss during a failure.

Setting Up Streaming Replication in PostgreSQL

Step 1: Configure the Primary Server

1. Modify postgresql.conf for replication:

• Open the configuration file (/etc/postgresql/<version>/main/postgresql.conf) and set the following:

wal_level = replica
max_wal_senders = 5        
wal_keep_size = 64

2. Update pg_hba.conf for replication user access:

• Add the following line to allow the replica to connect to the primary server:

host replication all 192.168.0.2/24 md5

• Replace 192.168.0.2 with the replica server’s IP address.

3. Restart the PostgreSQL service:

• Apply the changes by restarting the PostgreSQL service:

sudo systemctl restart postgresql

4. Create a replication user:

• Create a user with replication privileges:

CREATE ROLE replication_user REPLICATION LOGIN ENCRYPTED PASSWORD 'strongpassword';

Step 2: Prepare the Replica Server

1. Take a base backup of the primary server:

• On the replica server, take a consistent snapshot of the primary using the following command:

pg_basebackup -h 192.168.0.1 -U replication_user -D /var/lib/postgresql/12/main -Fp -Xs -P

• Replace 192.168.0.1 with the primary server’s IP address.

2. Configure the replica for streaming replication:

• Create a standby.signal file and set up the connection to the primary by adding the following to the replica’s postgresql.conf:

primary_conninfo = 'host=192.168.0.1 port=5432 user=replication_user password=strongpassword'

3. Start the replica PostgreSQL service:

• Start the PostgreSQL service on the replica server:

sudo systemctl start postgresql

Step 3: Verifying Replication Status

1. On the primary server:

To check if the replica is connected, run:

SELECT * FROM pg_stat_replication;

2. On the replica server:

• Verify that the replica is receiving WAL logs by running:

SELECT * FROM pg_stat_wal_receiver;

Example: Testing Streaming Replication

We can test PostgreSQL streaming replication by creating a table and inserting data on the primary server, then checking if the data appears on the replica server.

1. On the Primary Server: Create a new table and insert data.

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    department VARCHAR(50)
);

INSERT INTO employees (name, department)
VALUES ('Alice', 'Engineering'), ('Bob', 'Marketing');

2. On the Replica Server: Query the employees table to verify data replication.

SELECT * FROM employees;

Output:

Explanation:

The data inserted into the primary server is immediately visible on the replica, confirming successful replication.

Failover and Switchover

In case the primary server fails, we can promote the replica to take over as the new primary server.

1. Promote the replica to primary:

pg_ctl promote -D /var/lib/postgresql/12/main

2. Reconfigure the failed primary as a replica (optional): Once the primary server is fixed, you can set it up as a replica to maintain the replication setup.

Conclusion

PostgreSQL replication keeps your data safe and accessible by copying changes from a primary server to a replica server. If the primary server fails, the replica can take over by minimizing downtime and data loss.

This setup also helps balance the load by letting the replica handle some of the read requests, improving performance. Overall, replication ensures your database remains reliable and efficient.