Implement Oracle GoldenGate HA in OCI using Shared Storage
This article will cover the approach for implementing Oracle GoldenGate HA in OCI with Microservices, that involves configuring two nodes of virtual machines installed with GoldenGate MSA. By leveraging the Shared Storage and Auto Restart feature, Oracle GoldenGate can continue to function in the event of a VM failure by transferring and restarting the processing on another available VM that is configured for high availability in a different Availability Domain.
The Oracle GoldenGate Microservices Architecture (MA) is a modern architecture that shares similarities with REST APIs. It is desinged to simply the configuration, monitoring, and management of Oracle GoldenGate services through a user interface that is web-based.
GoldenGate Classic follows a monolithic architecture, where all GoldenGate components are installed on a single server. In contrast, GoldenGate Microservices follows a modular architecture that separates different components into independent services, accessible through RESTful APIs.
In a standard Microservices Architecture (MSA) setup, the Oracle GoldenGate processes operate within a HUB Architecture on a single-node VM, carrying out Remote Extract and Remote Apply.
The Oracle GoldenGate Microservices Architecture (MA) is a modern architecture that shares similarities with REST APIs. It is desinged to simply the configuration, monitoring, and management of Oracle GoldenGate services through a user interface that is web-based.
GoldenGate Classic follows a monolithic architecture, where all GoldenGate components are installed on a single server. In contrast, GoldenGate Microservices follows a modular architecture that separates different components into independent services, accessible through RESTful APIs.
In a standard Microservices Architecture (MSA) setup, the Oracle GoldenGate processes operate within a HUB Architecture on a single-node VM, carrying out Remote Extract and Remote Apply.
Solution Overview
The diagram above illustrates an ACTIVE/PASSIVE environment for achieving high availability with GoldenGate.
- Two VMs are set up in this configuration – one provisioned in AD-1 and the other provisioned in AD-2.
- Block Storage of 200 GB has been assigned to VM-1.
- Create a Shared Storage and attach it to both the Virtual Machine i.e. VM-1 and VM-2.
- In this article, Gluster shared storage service has been used as shared storage in both the VM’s. For additional information on configuring block storage as Gluster shared storage, please refer to my other blog post Gluster Shared Storage On OCI.
- Install the GoldenGate MSA binaries.
- Install the Service Manager components on both VMs and ensure that they are UP and RUNNING on both nodes.
- Create DEPLOYMENT with an identical name.
Create DEPLOYMENT with an identical name
Ensure to create the identical deployment on both VM-1 and VM-2. In this case the the deployment name is “VM2-DEPLOY”
Synchronize DEPLOYMENT Directories across VM-1 and VM-2
VM-1 Directory Structure : /REP_STORAGE/VM-1
drwxrwxr-x. 4 opc opc 28 May 4 16:56 DEPLOY
drwxrwxr-x. 15 opc opc 4096 May 4 16:42 MA
drwxrwxr-x. 5 opc opc 39 May 4 16:56 SM
VM-1 Directory Structure : /REP_STORAGE/VM-2
drwxrwxr-x. 4 opc opc 28 May 4 23:28 DEPLOY
drwxrwxr-x. 15 opc opc 4096 May 4 18:05 MA
drwxrwxr-x. 5 opc opc 39 May 4 18:10 SM
Rename the DEPLOY directory on VM-2 as DEPLOY_ORG
Create a softlink from VM-1 to VM2 :
ln -s /REP_STORAGE/VM-1/DEPLOY /REP_STORAGE/VM-2/
Directory Structure on VM-2 looks like below
lrwxrwxrwx. 1 opc opc 24 May 4 23:37 DEPLOY -> /REP_STORAGE/VM-1/DEPLOY
drwxrwxr-x. 4 opc opc 28 May 4 23:28 DEPLOY_ORG
drwxrwxr-x. 15 opc opc 4096 May 4 18:05 MA
drwxrwxr-x. 5 opc opc 39 May 4 18:10 SM
SCREENSHOT after SYNC
Extract and Replicat processes are created in VM-1, that automatically display in VM-2.
How to create AUTORESTART for EXTRACT/REPLICAT Process
Now let’s KILL/STOP VM-1 and check AUTORESTART on VM-2 will start up the GoldenGate process.
The GoldenGate process on VM-2 has successfully started without any manual intervention.
How to determine on which VM with the ACTIVE GoldenGate Process is running.
Add the below piece of code in the bashrc file
## To determine the Active GG Process #####
HOSTNAME=$(hostname)
if [ $(ps -ef | grep -c "extract PARAMFILE\|replicat PARAMFILE") -gt 1 ];then
GG_STATUS="GG ACTIVE"
PS1='[$USER@\[\033[1m\]'"${GG_STATUS}"'\[\033[0m\] on \[\033[1m\]\h\[\033[0m\]]\$ '
fi
if [ "$(ps -ef | grep -c 'extract PARAMFILE\|replicat PARAMFILE')" -eq 1 ]; then
GG_STATUS="GG PASSIVE"
PS1="[$USER@${GG_STATUS} on \h]"
fi
Re-Logging into the VMs will display the status of the node as either ACTIVE/PASSIVE.
After the failover, VM-2 is now the ACTIVE node, while VM-1 is the PASSIVE node.
SUMMARY
In this article, we demonstrated an ACTIVE/PASSIVE GoldenGate hub environment. This setup ensures that if the active GoldenGate hub encounters an interruption or is unintentionally stopped or the process gets killed, the GoldenGate process remains uninterrupted when the passive GoldenGate hub takes over and start as ACTIVE.
For more information about GoldenGate see the oracle official documentation here.
Hope you found this article useful.
Disclaimer: The views expressed on this document are my own and do not necessarily reflect the views of Oracle.
Please note that this solution is not certified by Oracle. Therefore, it is essential to thoroughly test and implement it at your own risk.
For more information about GoldenGate see the oracle official documentation here.
Hope you found this article useful.
Disclaimer: The views expressed on this document are my own and do not necessarily reflect the views of Oracle.
Please note that this solution is not certified by Oracle. Therefore, it is essential to thoroughly test and implement it at your own risk.