SharePlex 12.0 - Installation and Setup guide

Demonstration of replication for PostgreSQL

This section demonstrates the speed and accuracy of SharePlex replication. It can also be used to verify that SharePlex was installed and configured correctly. For detailed information, see Demonstration of replication.

Demonstration of named post queues for PostgreSQL

This demonstration shows you how to use named post queues to process different tables through different, parallel Post processes to improve performance.

Clean up the replication environment

NOTE: The demonstration objects are assumed to be in the schema named splex.

Perform the following steps to clean up the replication environment:

1. If you ran previous demonstrations, do the following:

   1. On the source and target, run sp_ctrl and issue the following command to shut down sp_cop.

      sp_ctrl(source)shutdown

      sp_ctrl(target)shutdown

   2. On the source and target, run the pg_cleansp utility according to the instructions in SharePlex utilities. This removes the queues from the previous demonstrations and deactivates the previous configuration.

2. On the source, TRUNCATE the splex.demo_src. SharePlex replicates the TRUNCATE to the target.

   truncate table splex.demo_src;

Create a configuration file

Perform these steps on the source system. The demonstration objects are assumed to be in the schema named splex.

You will configure the following:

• demo_src on the source replicates through a post queue named q1 to target demo_dest.
• demo_dest on the source replicates through a post queue named q2 to target demo_src.

1. Run sp_ctrl.

2. Issue the following command to create a configuration file named postq_config in the default text editor.

   sp_ctrl(source)>create config postq_config

3. In the text editor, build your configuration file based on the appropriate template, as shown in the Configuration templates. Allow no spaces between the characters in a component (source specification, target specification, routing map), and place at least one space between each component.

4. Save the file, then exit the editor. SharePlex automatically saves the file in the config sub-directory of the variable-data directory.

5. In sp_ctrl, verify that the configuration file will activate successfully.

   sp_ctrl(source)>verify config postq_config

Configuration templates

PostgreSQL to PostgreSQL

where:

• dbname is the database name of the source database

• splex is the database user of the target database

• database_name is the name of the open target database.

Activate the configuration

Important!Make certain you created the scripts described in Prework for the demonstrations.

Perform these steps on the source system. When you activate a configuration, SharePlex is ready to capture transactional changes that are made to the specified source data.

Perform the following steps to activate the configuration:

1. Activate the configuration.

   sp_ctrl(source)>activate config postq_config

   Note: Configuration names are case-sensitive.

2. Confirm that the configuration activated successfully. The name postq_config should appear under File Name, and the word Active should appear under State.

   sp_ctrl(source)>list config

Generate data

On the source, run the following scripts to insert data into the two local demonstration tables (in this demonstration, the demo_dest table is used as a source):

• Run the insert_demo_src script to insert 500 rows into the splex.demo_src table.
• Run the insert_demo_dest script to insert 500 rows into the splex.demo_dest table.

View the post queues

Perform the following steps to view the post queues:

1. On the target, run sp_ctrl.

2. On the target, issue the show post command with the detail option. This command shows statistics about the number of messages processed and the queues that were used.

   sp_ctrl(target)>show post detail

   In the output, the Queue field shows the name of each post queue, in this case q1 and q2, and the Operations Posted field shows the number of operations that were posted. Each queue should show 500 operations posted.

Advanced SharePlex Demonstrations for PostgreSQL

Contents

This chapter demonstrates selected features of SharePlex. These exercises can be run on Unix and Linux systems to demonstrate:

• How to build and verify a replication configuration
• How to use generic conflict resolution in peer-to-peer replication

Demonstration of Conflict Resolution - PostgreSQL to PostgreSQL

Demonstration of conflict resolution - PostgreSQL to PostgreSQL

In this demonstration, you will configure SharePlex to use generic conflict resolution procedures to resolve a replication conflict. Generic conflict resolution allows you to use one PL/SQL procedure to resolve conflicts for multiple tables.

The following conflict-resolution strategy is demonstrated:

• Trusted-source priority – In the following steps, you will define one system as the “trusted” source that takes priority in the event of a conflict. This demonstration is based on INSERTs. All INSERTs that originate on the trusted source will override INSERTs from the other system. In this demonstration, the trusted source is peer1 and the other system is peer2.
• Timestamp priority – This demonstration is based on UPDATEs. When there is a conflict, the row that was updated LAST prevails.

IMPORTANT! Peer-to-peer replication is not compatible with all business applications. When suitable for an environment, it requires careful analysis and execution, including the creation of custom conflict resolution procedures that are typically more complex than those in this demonstration. Do not use this demonstration as the foundation of a production peer-to-peer deployment. For more information about peer-to-peer replication, see the SharePlex Administration Guide.

Pre-work for the demonstrations

Install the demonstration objects as described below before you start the demonstrations.

Note: To run the scripts, set Replica Identity to Full for tables that are a part of replication.

Install the demonstration objects

The pg_p2p.sql and pg_od.sql scripts install the demonstration objects that you will use during these demonstrations. These scripts are stored in the util sub-directory of the SharePlex product directory.

To run the scripts:

• Run pg_od.sql first, then run pg_p2p.sql.
• Run the scripts on the source and target systems that you will be using for the demonstrations.
• Run them in PSQL as an existing user with the DBA role.

Note: The scripts prompt for the schema where you want the demonstration objects need to be installed. Additionally, pg_p2p.sql prompts for the name of the system that will be the trusted source of accurate data.

Description of the demonstration objects

od_employee

exc_table

exc_source

Note: Apart from these tables, other demonstration objects are also created those are not part of this demonstration.

Prepare the objects

Note: In this demonstration, the demonstration objects are assumed to be in the schema named demo. Substitute the actual schema, if different.

Perform these steps on both systems (for both databases).

1. Run sp_ctrl.

2. Shut down SharePlex.

   sp_ctrl(peer1)>shutdown

3. Run the pg_cleansp utility. This removes the queues from the previous demonstrations and deactivates the previous configuration.
4. TRUNCATE  the od_employee tables.
5. Log into PSQL as the user who owns the SharePlex demonstration objects.

6. Run the pg_p2p.sql script from the util sub-directory of the SharePlex product directory. This installs the od_employee_gen demonstration conflict resolution routine. You are prompted for the following:

   • A schema for the procedure
   • The name of the system that will be the trusted source of accurate data (pri_system). As in a production deployment, operations the trusted source take priority during a conflict. This system is known as peer1 in this demonstration. The other system is known as peer2 in this demonstration.
7. Set the Replica Identity to Full for the od_employee tables.

Configure SharePlex

Perform these steps to configure SharePlex:

1. On each system, open the conflict_resolution.database file in a text editor. This file is located in the data sub-directory of the SharePlex variable-data directory.

   Note: Post checks this file when there is a replication conflict to determine if there is a resolution procedure to call.

2. On each system, create the following entries in the conflict_resolution.database file. Separate each column with at least a few spaces or a tab character.

   demo.od_employee

   IUD

   demo.od_employee_gen

   Note: The first component is a table, the second specifies the operation types for which a resolution routine will be called if there is a conflict on that table, and the third is the name of the resolution routine that will be used.

3. On each system, start sp_cop.
4. On each system, start sp_ctrl.

5. On peer1 (the trusted source), create a configuration file named od_peer1 that replicates the od_employee table to the od_employee table on peer2.

   sp_ctrl(peer1)> create config od_peer1

   demo.od_employee

   demo.od_employee

   peer2@r.database

6. On peer2 (the secondary source), create a configuration file named od.peer2 that replicates the od_employee table to the od_employee table on peer1.

   sp_ctrl(peer2)> create config od_peer2

   demo.od_employee

   demo.od_employee

   peer1@r.database

Activate and start replication

Perform these steps to activate and start replication:

1. On peer1, activate the od_peer1 configuration.

   sp_ctrl(peer1)> activate od_peer1

2. On peer2, activate the od_peer2 configuration.

   sp_ctrl(peer2)> activate od_peer2

3. On each system, confirm that the configuration activated successfully. The name od_peer1 or od_peer2 (depending on the system) should appear under File Name, and the word Active should appear under State.

   sp_ctrl(source)>list config

Demonstrate trusted-source priority

In this demonstration, an INSERT that originates on peer1 will override a conflicting INSERT that is replicated from peer2.

1. On both systems, stop the Export process.
2. On both systems, log in to PSQL as demo (the owner of the demonstration objects).

3. On peer2, insert a row into od_employee.

   insert into od_employee values(1, 'John', 'Doe', '1949-04-01', 1, '2022-01-01');

4. On peer1, insert the same row (same values).

   insert into od_employee values(1, 'John', 'Doe', '1949-04-01', 1, '2022-01-01');

5. On both systems, restart the Export processes.
6. This operation should generate a conflict, which Post resolves automatically based on instructions in the conflict_resolution.database file.
7. On both systems, view the demo.exc_table to verify that the conflict was resolved. See View the conflict resolution results.

Demonstrate timestamp priority

In this demonstration, whenever there is a conflict for an UPDATE statement, the row with the most current value of the emp timestamp column gets precedence.

Note: The EMP_TIMESTAMP field, along with the other columns, must be modified to a non-null value in order for timestamp priority to function. The stored procedure won't be able to resolve the conflict if the timestamp column in the UPDATE statement is not being updated or is being modified to a null value. Out-of-sync problems will then be seen.

1. On both systems, stop the Export process.
2. On both systems, log in to PSQL as demo (the owner of the demonstration objects).
3. On peer1, update the emp_first_name and EMP_TIMESTAMP columns of the od_employee table as follows:
   update od_employee set emp_first_name = 'James', emp_timestamp = '2022-07-01' where emp_no = 1;
4. On peer2, update the same columns using a different update value but the same key value.
   update od_employee set emp_first_name = 'Harry', emp_timestamp = '2022-08-02' where emp_no = 1;
5. On both systems, restart the Export processes.
6. On both systems, select the row that you updated to verify that it contains the most recent emp_ timestamp value.
7. On both systems, view the demo.exc_table to verify that the conflict was resolved. See View the conflict resolution results.

Demonstrate no conflict resolution

In this demonstration, if a DELETE statement generates a conflict, it is ignored.

1. On both systems, stop the Export process.
2. On both systems, log in to log in to PSQL as demo (the owner of the demonstration objects).
3. On peer1, delete a row as follows.
   delete from od_employee where emp_no = 1;
4. On peer2, delete the same row.
   delete from od_employee where emp_no = 1;
5. On both systems, restart the Export processes.
6. On both systems, view the demo.exc_table to verify that the conflict is not resolved. See View the conflict resolution results.

View the conflict resolution results

A table named exc_table was installed in the schema that you specified when you installed the demonstration objects. You can view it through PSQL to view information about each conflict. The following is the table description.