Initial Configuration of Oracle GoldenGate Replication

Language:

This section describes the steps you need to perform to configure the Oracle GoldenGate software on the primary and secondary clusters:

Installing Oracle GoldenGate and Configuring the Oracle GoldenGate Resource Group

You can install Oracle GoldenGate and configure both clusters as described in Oracle Solaris Cluster Data Service for Oracle GoldenGate Guide.

The resource group and its resources do not have to have the same name on both clusters.

When you configure the Oracle GoldenGate resource, keep the following restrictions in mind:

Configuration of a database resource as a Service Management Facility (SMF) component on top of a failover container resource is not allowed.
Oracle GoldenGate replication between the two clusters must be the only Oracle GoldenGate replication configured between the two databases.

Configuration Restrictions

Caution - Your replication configuration might not be supported if you do not observe these restrictions.

For restrictions that apply to all other Disaster Recovery Framework replications, see the release notes for your release of Disaster Recovery Framework. The following configuration restriction applies only to Oracle GoldenGate.

Since Oracle GoldenGate replication must be configured only in the active-active topology, it is essential to have replication conflict detection and resolution (CDR). For example, a replication conflict could occur when the same record with the same key entry is inserted in a unique key on both sides at the same time. CDR is an Oracle GoldenGate configuration task and cannot be performed by Oracle Solaris Cluster.
Although HA for Oracle GoldenGate supports multiple master deployments, Oracle GoldenGate replication in the Disaster Recovery Framework does not support such a deployment. Replicating a multiple master configuration in an active-active topology is not supported.
The Oracle GoldenGate resource must be co-located with the database resource. To achieve this in a failover configuration, you can always place them in the same resource group. If you do not want the resources in the same resource group, define strong positive affinities or strong positive affinities with failover delegation between the resource groups.
Ensure that the Oracle GoldenGate user login process is not interactive. For example, the su - gg-user command must not require any additional inputs from the user.

Configuration Requirements

Caution - Configuration requirements represent actions that you must perform. If your replication configuration does not satisfy these requirements, the replication configuration might not be supported.

For requirements that apply to all replications in Disaster Recovery Framework, see Administering the Disaster Recovery Framework for Oracle Solaris Cluster 4.4.

The following configuration requirements apply only to Oracle GoldenGate.

Use HA for Oracle GoldenGate to make Oracle GoldenGate highly available. For more information, see Oracle Solaris Cluster Data Service for Oracle GoldenGate Guide.
Oracle GoldenGate must be configured only in the active-active topology for your database. For information on how to configure Oracle GoldenGate for your database, see the Oracle GoldenGate documentation.
Failed extracts and replicats between clusters or within a cluster must be restarted automatically by Oracle GoldenGate.

Configuring the Oracle GoldenGate Application Resource Group

Create the application resource groups on the primary and the secondary clusters and set the Auto_start_on_new_cluster to false. This resource group hosts application resources for the application that used the database that Oracle GoldenGate is replicating. You also need to add the logical host resources as the replicated database requires them for connection. See the appropriate data services chapter for details on the installation and configuration of your data service.

The following commands show creation of the resource group while setting the Auto_start_on_new_cluster property to false and the creation of a logical host resource on the primary cluster, cluster-paris:

phys-paris-1# clresourcegroup create -p Auto_start_on_new_cluster=false usa-rg
phys-paris-1# clreslogicalhostname create -g usa-rg cluster-usa

phys-newyork-1# clresourcegroup create -p Auto_start_on_new_cluster=false usa-rg
phys-newyork-1# clreslogicalhostname create -g usa-rg cluster-usa