SharePlex 11.4 - Installation and Setup guide

Configure SharePlex on PostgreSQL Azure Flexible Server with High Availability Using Logical Replication

SharePlex supports HA with logical replication on PostgreSQL Azure Flexible Server.

Follow the below configuration steps:

1. Enable high availability setup on Azure Flexible Server using the steps provided in the link below:

   https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-manage-high-availability-portal#enable-high-availability-post-server-creation

   important: Users should be able to access the database using the primary server name (host name).

2. Create pg_failover_slots extension setup using the steps provided in the link below:

   https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions#pg_failover_slots-preview

   Note: The pg_failover_slots extension is supported for PostgreSQL version 11 to 15.

3. Use the servername = hostname under the DSN in the odbc.ini file. User should use this DSN during pg_setup.

   Example:

   [DSN]

   Servername=pslflexihaserver01.postgres.database.azure.com

   Note: Do not use the IP address of the primary database server, as it may change after failover. As the hostname always points to the current primary database server, we should use only the host name.

4. Stop the Capture process before the failover and restart it afterward, in the event of a planned failover.

   In the event of an unplanned failover, the Capture process will stop due to an error state after the failover and will need to be manually restarted.

Limitation: If consecutive failovers occur, before initiating the capture following the initial failover, the pg_failover_slots extension will remove logical slots from both the primary and standby servers. The reason is that after the first failover, the slot on the standby is marked as active and the slot on the primary is marked as inactive. An active state of 'true' on the standby indicates that the slot has not yet synchronized and is not safe for use. Hence, when the failover happens again, the slot on the new primary is lost. To avoid the removal of slots on the primary and standby servers, the user must start the capture after each failover. So, the extension should ideally mark the slot on the standby as inactive (as it being inactive means it is safe to replicate). For additional information, see https://github.com/EnterpriseDB/pg_failover_slots/issues/25.

Generic SharePlex Demonstration for PostgreSQL

Contents

Prework for the demonstrations

Before you run the basic demonstrations, have the following items available.

Tables used in the demonstrations

You will replicate splex.demo_src from the source system to splex.demo_dest on the target system. These tables are installed by default into the SharePlex schema, which in these demonstrations is "splex." Your SharePlex schema may be different. Verify that these tables exist.

Description of the demo tables.

INSERT scripts

• Create a SQL script named insert_demo_src that inserts and commits 500 rows into the splex.demo_src table. You will run this script during some of the demonstrations.
• If you will be using the demonstration of named post queues, create a SQL script named insert_demo_dest that inserts and commits 500 rows into the splex.demo_dest table. You will run this script during some of the demonstrations.

Start SharePlex

Start SharePlex

The following are instructions for starting SharePlex and the sp_ctrl command-line interface on Unix and Linux. Start SharePlex on the source and target systems.

To start SharePlex on Unix and Linux systems:

1. Log onto the system as a SharePlex Administrator (a member of the SharePlex Admin group).

2. From the bin sub-directory of the SharePlex product directory ( productdir in the following syntax), run sp_cop and sp_ctrl.

   $cd /productdir/bin

   $./sp_cop &

   $. /sp_ctrl