In one of our previous blogs, a custom method for switching from PostgreSQL physical replication to logical replication was discussed, using pg_create_logical_replication_slot and pg_replication_slot_advance. PostgreSQL 17, set to be released this year, introduces the pg_createsubscriber utility, simplifying the conversion from physical to logical replication. This post will cover using pg_createsubscriber to convert physical to logical replication and avoid the initial data copy.

Prerequisites

  • Source and target servers must have the same major PostgreSQL version as pg_createsubscriber.
  • The target data directory must have the same system identifier as the source.
  • The user for the target data directory must have privileges for creating subscriptions and using pg_replication_origin_advance().

Primary server

  • Must accept connections from the target server.
  • Must not be in recovery.
  • wal_level must be set to logical.
  • max_replication_slots >= number of specified databases + existing replication slots.
  • max_wal_senders >= number of specified databases + existing WAL sender processes.

Physical standby

  • The target server must be used as a physical standby.
  • max_replication_slots and max_logical_replication_workers >= number of specified databases.
  • max_worker_processes > number of specified databases.
  • Must accept local connections.

Please refer to some of these blog posts from Percona to learn more about logical replication.

Steps to use the pg_createsubscriber utility to convert a physical replica to a logical replica:

 The test servers are running the PostgreSQL 17 beta version, which includes the pg_createsubscriber utility.

  • Primary server: 172.31.42.65
  • Physical replica: 172.31.42.66

Validate prerequisites: Ensure both the primary server and the physical replica meet all prerequisites.

The primary server meets all required prerequisites.

The physical replica also meets the necessary prerequisites.

Verify setup:

Check if the primary and physical replica setup is working correctly. For help with setting up physical replication, refer to the PostgreSQL streaming replication blog post.

Physical replication is in place 

Conversion process:

The primary server has a Percona database with three tables. The goal is to convert the physical replication into logical replication for the Percona database using the pg_createsubscriber utility.

Stop the physical replica and execute the following command on the physical replica to convert it to a logical replica:

Conversion log:

Final steps:

The physical replica is now converted to a logical replica. Start the logical replica and check its status.

Confirm that the logical slot and publication have been created on the primary server.

On the logical replica, verify that the subscription is active.

Pros and cons of pg_createsubscriber

Pros:

  • All tables in the specified databases are included in the logical replication setup.
  • This method is beneficial for avoiding the initial data copy for large databases

Cons:

  • The major version must be the same on both servers.
  • If pg_createsubscriber fails after the target server is promoted, rebuilding the physical replica will be necessary.

Converting a physical replica to a logical replica using the pg_createsubscriber utility in PostgreSQL 17 simplifies the process. Following these steps makes the transition seamless, ensuring the logical replication setup is active and operational. 

References


Our services and software are designed to make running high-performance, highly available PostgreSQL in critical environments practically effortless. They enhance PostgreSQL with security and performance features that are all certified and tested to work seamlessly together.

 

Why Customers Choose Percona for PostgreSQL

Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments