SharePlex 11.4 - Installation and Setup guide

Install SharePlex on PostgreSQL High Availability Cluster

SharePlex supports CrunchyData High Availability cluster environment setup.

Follow the below configuration steps:

1. Setup the CrunchyData High Availability cluster environment according to the CrunchyData setup documentation.

2. Install or upgrade to SharePlex 11.1.

3. Run the pg_setup utility and enter a slot name.

4. Activate the configuration. The user input slot name will be created in the database after a successful activation.

5. Add the slot name to the respective CrunchyData config [YML or YAML] file to monitor in failover or switchover scenario.

6. Run the deactivate configuration or cleanup [pg_cleansp] utility to remove the dedicated slot name from the database. Users need to remove SharePlex dedicated slot name from the CrunchyData config file.

7. Remove the SharePlex dedicated slot name from the CrunchyData config file.

Example of CrunchyData config command: patronictl -c /etc/patroni/crunchy-demo.yml edit-config

NOTE: User need to add SharePlex dedicated slot name to the respective CrunchyData config.

Limitation: SharePlex internally uses PostgreSQL logical replication with a PostgreSQL database over cloud services. In the event of a failover to the standby server, the logical replication slots are not copied over to the standby server on cloud database services; hence, SharePlex will not handle logical slot re-creation and maintenance with cloud database services. This applies to the AWS Multi-AZ cluster setup of the RDS PostgreSQL, and the Aurora PostgreSQL databases.

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.