These instructions show you how to set up SharePlex for the purpose of high availability: replicating to a secondary Oracle database that is a mirror of the source database. This strategy uses bi-directional replication with two SharePlex configurations that are the reverse of each other. The configuration on the secondary (standby) machine remains in an activated state with the Export process on that system stopped in readiness for failover if the primary machine fails.

Note: For CrunchyData High Availability cluster environment setup information, see the Install SharePlex on PostgreSQL High Availability Cluster section in the SharePlex Installation and Setup Guide.

This strategy supports business requirements such as the following:

• Disaster recovery
• Continuous operation of business applications throughout maintenance cycles or mechanical failures

In this strategy, SharePlex operates as follows:

• Under normal conditions, SharePlex replicates changes from the primary database to the secondary database.
• When the primary system or database is offline and users are transferred to the secondary system, SharePlex captures their changes and queues the data on that system until the primary system is restored.
• When the primary system is restored, SharePlex updates it with those changes and then resumes capture and replication from the primary database.

Supported sources

Oracle and PostgreSQL

Supported targets

Oracle

Capabilities

This replication strategy supports the use of named export and post queues.

Note: Column mapping and partitioned replication is not appropriate in a high availability configuration. Source and target objects can have different names but this makes the management of a high-availability structure more complicated.

Requirements

• Prepare the system, install SharePlex, and configure database accounts according to the instructions in the SharePlex Installation Guide.
• All objects must exist in their entirety on both systems.
• The target objects must have the same structure and qualified names as their source objects.

• Enable archive logging on all systems.

• Create a script that denies INSERT, UPDATE and DELETE operations to all users except SharePlex.

For failover purposes, the following are required:

• Make the applications used on the primary system available on the secondary system.
• Copy non-replicated database objects and critical files outside the instance to the secondary system.
• Create a script that grants INSERT, UPDATE and DELETE privileges to all users, which can be run during a failover procedure.
• Create a script that enables constraints on the secondary system to be used during a failover procedure.
• Develop a failover procedure for relocating users to the secondary system.

Note: If you use an Oracle hot backup to create the secondary instance, keep the script. It can be modified to re-create the primary instance.

Conventions used in the syntax

In the configuration syntax in this topic, the placeholders represent the following:

• hostA is the primary system.

• hostB is the secondary system.
• ownerA.object is the fully qualified name of an object on hostA or a wildcarded specification.
• ownerB.object is the fully qualified name of an object on hostB or a wildcarded specification.
• oraA is the Oracle instance on hostA.
• oraB is the Oracle instance on hostB.

Important! See Configure SharePlex to Replicate Data for more information about the components of a configuration file.

Configuration

A high availability configuration uses two configurations that are the reverse of each other. To replicate all objects in the database, you can use the config.sql script to simplify the configuration process. For more information, see the Configuration Scripts section in the SharePlex Reference Guide.

Configuration on the source system (primary system)

Datasource:o.oraA
ownerA.object	ownerB.object	hostB@o.oraB

Configuration on the target system (secondary system)

Datasource:o.oraB
ownerB.object	ownerA.object	hostA@o.oraA

Make the system ready for failover

1. On the secondary system (the one that will initially be the passive system) run sp_ctrl and then issue the following command to stop the Export process on the secondary system so that nothing accidentally happening on the secondary system (such as a scheduled job changing data) gets replicated back to the primary system. This is the required state of SharePlex on that system until there is a need for a role switch between systems.
2. Perform initial synchronization and startup. You will activate the source configuration during this procedure. For more information, see Start Replication on your Production Systems.
3. Making sure the Export process is stopped on the secondary system, activate the configuration on that system. The configuration on the secondary machine remains in an activated state, but the stopped Export process and lack of user activity ensure that the system remains static in readiness for failover.
4. Monitor the SharePlex instance that is linked to the secondary Oracle instance to make sure no non-SharePlex DDL or DML changes were performed. You can do this as follows: View the status of the export queue on the secondary system using the qstatus command in sp_ctrl. The queue should be empty, because the Capture process on a system ignores the Post process on that system. If there are any messages in the export queue, it means those transactions originated on the secondary system or the SP_OCT_REPLICATE_POSTER parameter was mistakenly enabled. See the SharePlex Reference Guide for more information about SharePlex commands and parameters.
5. Maintain backups of replication files.

Perform recovery procedures

If a system fails in your high-availability environment, you can move replication to a secondary system and then move it back to the primary system when it is restored. For more information, see Recover Replication after Oracle Failover .