Configuring and installing OGG for High Availability (HA) differs very little from a single instance on Unix/Linux. The main difference is in the filesystem set up in a cluster environment so that all nodes in the cluster have access to the OGG installation. Following are the main guidelines for Unix/Linux and Windows. The software can be downloaded either from OTN or Oracle's eDelivery site.
The steps for configuring Oracle GoldenGate for high availability are as follows:
The following simple steps will unpack the software distribution and create the appropriate directory structure for OGG on Unix/Linux systems. Extract the OGG
mediapack.zipfile to the system and directory where you want the OGG installation to reside, for example,/GG mount point.as shown in the following commands:$ cd /GG $ unzip mediapack.zip $ ./GGSCI GGSCI> create subdirs GGSCI> exit
Next, if you are installing the software on a Windows server, follow these steps:
Log on to one of the nodes on the cluster.
Choose a drive for the installation. The drive must be a part of the resource group that contains the database, for example:
c:\GG.
Unzip the downloaded file in your installation directory by using WinZip or a similar compression tool by using the following commands:
c:\GG\ggsci GGSCI> create subdirs GGSCI> exit
Copy the
category.dllandggsmsg.dllfiles from the OGGrootdirectory to theSYSTEM32directory.Specify a custom manager name as follows:
C:\GG C:\GG\ggsci GGSCI> edit param ./GLOBALS
Add the following line to the file:
MGRSERVNAME <NAME>Where
<NAME>is an arbitrary one-word name for the Manager service.Save the file and exit.
We install the Manager as a Windows service so that it restarts upon server reboots.
Log in as the system administrator. Open the Run dialog then type
cmdin the Run dialog box.Change directory to the OGG installation home directory and install the service as follows:
C:\GG\install addservice autostart
As a best practice it is better to install the OGG binaries entirely on shared storage. In this fashion, you can start the OGG processes from any node of the cluster and not worry about making any parameter changes.
For example if /GG is the chosen mount point to host your OGG installation, make sure that this mount point is mounted as a cluster filesystem by your system administrator in every host of the cluster.
If the node that started the manager and Extract/Replicat (E/R) processes fails, you can restart the manager and E/R processes from any of the surviving nodes as the checkpoint's integrity is maintained and you don't need to make any parameter file changes.
If you decide to install the OGG binaries locally on each node of the cluster, than you need to consider the following:
Ensure you have the same location path of the OGG installation on each node.
The following directories should be at a minimum located on the shared storage such as NetApp/DBFS storage to meet recovery requirements. You should create symbolic links from the installation directories to the shared storage mount point.
brdirchkdirdatdirtmp
Create a symbolic link, for example, from the installation directory to the shared directory, as follows:
$ ln –s /ggtrail/dirdat /GG/dirdat $ ln –s /ggtrail/dirchk /GG/dirchk $ ln –s /ggtrail/br /GG/br $ ln –s /ggtrail/dirtmp /GG/dirtmp
The example uses
/ggtrailas the shared location for the preceding directories.Another important point is to ensure your parameter files are identical on each node with the exception of the environment variables that access your Oracle RAC instance.
Register the OGG Manager, and only the manager, as a cluster-managed resource. The OGG Manager process is the only cluster-management software that starts and stops since the Manager process is the parent process that manages all the other processes.
Ensure that all nodes in which OGG software runs are selected as possible owners of the resource.
Ensure that the Windows service Manager has the following dependencies from the Services control panel:
The database resource
The disk resource that contains the OGG installation
The disk resource that contains the database transaction logs
The disk resource that contains the database transaction log backup files
If the cluster uses Virtual IP (VIP) such as Oracle ClusterWare, make sure the VIP is a static IP and available on the public subnet.