Linking Oracle GoldenGate Classic Architecture to Oracle GoldenGate Microservices Architecture

In my last post I covered how to connect the microservices architecture to the classic architecture (here). For this post, I want to show you how to connect the GoldenGate Classic Architecture to the new GoldenGate Microservices Architecture.

You many be asking yourself, why do I want to do this? The answer is quite simple. At the current moment and time, there is no upgrade path to move from Classic to Microservices. This is due to the changes in architecture design for remote administration. If you want to make the leap to Microservices though, you can “migrate” to the architecture using this approach. Now this is only one version of migrating to Microservices. I’m calling this one the leap frogging … basically, you can set Microservices up as a target and start replicating to it. Once done and/or nsync, make a new target on the other side using Microservices to complete the configuration.

Before you can do a leap frog migration, you have to get your Classic Architecture to work with Microservices Architecture. In order to do this, you have to connect the Data Pump Extract (Classic Architecture) to the Reciever Service (Microservices Architecture). To keep this post, realtive short, I’m just going to focus on what you need to configured.

Some assumptions on environments:

1. Classic Extract is up and running. Capturing data and shipping it to the local trail location ($OGG_HOME/dirdat)
2. Microservices Architecture installed with at least one deployment. Reciever Services running on a specified port (in this example: 17003)
3. Replicat configured in Microservices Architecture to read remote trail file

Setting Up the Data Pump Extract (Classic Architecture):

At this point, you may have to modify your parameter file or create a new Data Pump Extract. For example purposes, let’s create a new Data Pump Extract.

1. Start GGSCI
cd $OGG_HOME
./ggsci

2. Add a Data Pump Extract
ggsci> ADD EXTRACT PSOE2SOE, EXTTRAILSOURCE ./dirdat/ca

3. Add remote trail to Data Pump Extract
ggsci> ADD RMTTRAIL cb, EXTRACT PSOE2SOE, MEGABYTES 200

Note: At this point, notice the remote trail file is not mentioning the “dirdat” directory. This is due to Microservices using a different directory structure for trail files. The Receiver Services will place the remote trail file where it needs to be for the Microservices Architecture.

4. Edit parameter file for the Data Pump Extract
ggsci> EDIT PARAMS PSOE2SOE

The contents of the parameter file are as follows:

EXTRACT PSOE2SOE
RMTHOST <hostname/IP address>, PORT <reciever service port>
RMTTRAIL cb
PASSTHRU
TABLE PDB1.SOE.ADDRESSES;

5. Start the Data Pump Extract
ggsci> START EXTRACT PSOE2SOE

After the extract starts, you should see a new path start up in the Reciever Service of the Microservices Architecture. The below image shows you an example of what this may look like.

A couple of things to notice here. The Reciever Service will be named with a default name. And the port number (17003) will highlight what protocol is being used (ogg). This approach will help you get moving towards the Microservices Architecture.

Enjoy!!!

Please follow and like: