Patch Oracle GoldenGate Microservices using RESTful APIs

In 2017, Oracle introduced the world to Oracle GoldenGate Microservices through the release of Oracle GoldenGate 12c (12.3.0.0.1). Upon the initial release, Oracle promoted the benefit of using the Microservices Architecture for new platforms and the ease of upgrading and patching. This document will show how an organization can start on one version of Oracle GoldenGate, install another version and migrate to that version with ease.

Platform

Oracle GoldenGate (Microservices) is now available on all the platforms Oracle supports for replication. This means organizations should have already installed Oracle GoldenGate (Microservices) and have environments replicating data. If so, then there will be times that these environments need to be upgraded or patched. To make upgrading or patching easier, Oracle has implemented an out-of-place upgrade or patching approach for Oracle GoldenGate.

With any Oracle GoldenGate (Microservices) environment, there are two home directories that an administrator needs to be concerned with. These homes are:

• $OGG_HOME -> Oracle GoldenGate Home
  
• $DEPLOYMENT_HOME -> Oracle GoldenGate Deployment Home
  

These homes are essential for Oracle GoldenGate (Microservices) to run. However, when it comes to upgrading or patching, only the Oracle GoldenGate Home ($OGG_HOME) is required. When you review Oracle GoldenGate Home, organizations will notice that the directory structure mimics a Linux/Unix filesystem-based similar to the Oracle Database. This approach makes it easier for Oracle GoldenGate to merge into the patching processes that are already industry standards.

At the same time, by only needing the Oracle GoldenGate Home for patching, there are no interruptions to existing Oracle GoldenGate processing. This approach lets you install a second Oracle GoldenGate Home, the patch that home, then migrates processes over to the new home. You are facilitating a near-zero downtime patching approach.

Patching

Organizations need to patch their Oracle GoldenGate Homes for patching to be effective. To do this without taking an outage within the replication environment, installing a second Oracle GoldenGate Home is key.

Second Home

To install a second Oracle GoldenGate Home, organizations need to install the Oracle GoldenGate (Microservices) binaries in a new directory structure (outside of their existing Oracle GoldenGate Home). This can be done by doing the following:

1. Download the required binaries
   
2. Install binaries into the new Oracle GoldenGate Home
   

After downloading the required binaries, these binaries can be installed using the same processes that an organization has established. For this example use case, installing the binaries is done by a silent install process. See below:

1. Update the Oracle GoldenGate Core response file (oggcore.rsp)
   
2. Install the new Oracle GoldenGate Home$ cd /tmp/ogg21cma/ggs*/Disk1
   $ ./runInstaller -silent -ignoreSysPrereqs -ignorePrereq -showProgress -waitForCompletion -responseFile /tmp/oggcore1.rsp
   

Once the install is done, there are now two Oracle GoldenGate (Microservices) homes within the environment.

PatchSet

With both Oracle GoldenGate Homes in place, the next step is to patch the Second Home with the patches required. The following steps are used to install the Oracle GoldenGate patch to the Second Home:

1. Copy the patch set over to the host where Oracle GoldenGate (Microservices) runs. Use any tool that will facilitate moving the zip file.
   
2. Unzip the patch in the temp directory
   

   $ unzip -q ./ p33846655_215000_Linux-x86-64.zip -d .
   

3. Apply the patch
   

   $ export ORACLE_HOME=$ORACLE_HOME
   $ cd /tmp/33846655
   $ $ORACLE_HOME/OPatch/opatch apply
   

4. Validate that the patch has been applied$ $ORACLE_HOME/OPatch/opatch lsinventory
   

After validating that the patch has been installed, the next thing is to migrate the ServiceManager and associated deployments to the new Oracle GoldenGate (Microservices) Home.

List Deployments

With the new Oracle GoldenGate (Microservices) Home patched, each corresponding deployment home must be migrated to the latest Oracle GoldenGate (Microservices) Home. This can be done in two different approaches – GUI and RESTful API. The most straightforward approach to performing the migration is using RESTful APIs.

Before migrating any deployments between Oracle GoldenGate (Microservices) Homes, it is good to see what deployments exist on the server. This can be done using the following CURL command:

curl –location –request GET ‘HTTP://<host>:<port>/services/v2/installation/deployments’ \
–header ‘Authorization: Basic b2dnYWRtaW46V0VsY29tZTEyMzQ1IyM=’ 

The resulting output would be a list of deployments that the ServiceManager is responsible for:

{
“$schema”: “api:standardResponse”,
“links”: [
{
“rel”: “canonical”,
“href”: “http://<host>:<port>/services/v2/installation/deployments”,
“mediaType”: “application/json”
},
{
“rel”: “self”,
“href”: ” http://<host>:<port>/services/v2/installation/deployments “,
“mediaType”: “application/json”
},
{
“rel”: “describedby”,
“href”: ” http://<host>:<port>/services/v2/installation/deployments “,
“mediaType”: “application/schema+json”
}
],
“messages”: [],
“response”: {
“$schema”: “ogg:installationDeployments”,
“xagEnabled”: false,
“deployments”: [
{
“deploymentId”: “cf638afd-252e-4c79-ad55-fbeccb5d0434”,
“deploymentName”: “Kafka”,
“enabled”: true,
“status”: “running”
},
{
“deploymentId”: “dc31de7c-39aa-4de2-a3df-5451e32ccef6”,
“deploymentName”: “ServiceManager”,
“enabled”: true,
“status”: “running”
}
]
}
}

In this output from the CURL command, the “deploymentName” key will tell you the current deployment (s) installed on the host. In this example, both the ServiceManager and the Kafka deployment homes have to be migrated to the new Oracle GoldenGate (Microservices) Home.

Patch ServiceManager via OGG_HOME

To patch the ServiceManager deployment, organizations must update what Oracle GoldenGate (Microservices) Home the ServiceManager references. To do this, the following CURL command can be executed:

curl -L -X PATCH ‘http://<host>:<port>//services/v2/deployments/ServiceManager’ \
-H ‘Content-Type: application/json’ \
-H ‘Authorization: Basic b2dnYWRtaW46WFVNQEQzWXh1NWJpWmtGSQ==’ \
–data-raw ‘{
     “oggHome”:”/app/orabd1″,
    “status”:”restart”
}’

This CURL command feeds raw data that tells Oracle GoldenGate to update the deployment with an updated Oracle GoldenGate Home. Once the update has been completed, the ServiceManager will be restarted. After the restart, log in to the ServiceManager and confirm that the Oracle GoldenGate Home for the ServiceManager has been updated. Image 1 below shows what it would look like.

Image 1: ServiceManger Updated

Patching Deployment via OGG_HOME

Any associated deployments can be migrated after the ServiceManager has been patched via migration to a new Oracle GoldenGate (Microservices) Home. The only requirement for a deployment to be migrated is that the ServiceManager has to be on the same or later version of Oracle GoldenGate. This means that organizations can have multiple Oracle GoldenGate (Microservices) Homes running simultaneously, depending on their deployments. In this example, all deployments must be migrated to the latest patch set (i.e., patched).

To move a deployment, the process is precisely the same as was performed with the ServiceManager. To do this, the following CURL command can be executed:

curl -L -X PATCH ‘http://<host>:<port>/services/v2/deployments/Kafka’ \
-H ‘Content-Type: application/json’ \
-H ‘Authorization: Basic b2dnYWRtaW46V0VsY29tZTEyMzQ1IyM=’ \
–data-raw ‘{
“oggHome”:”/app/orabd1″,
“status”:”restart”
}’

Once the deployment is restarted, all the Oracle GoldenGate processes (extract and replicat) will be upgraded to the latest versions of the binaries. To verify that the deployment was updated, check the ServiceManager and confirm that the Deployments section has an updated Oracle GoldenGate Home for the deployment. Image 2 below shows what this would look like.

Image 2: Deployment Updated

Summary

Upgrading and Patching Oracle GoldenGate has always been an issue that takes time. In many cases, upgrading Oracle GoldenGate took six months to a year. Using Oracle GoldenGate (Microservices), an organization can quickly install, upgrade, or patch an environment with minimal downtimes. It is easing the time it takes to upgrade or repair, and the environment is critical as environments start to expand and data movement becomes key to organizational goals.

Please follow and like: