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
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:
RMTHOST <hostname/IP address>, PORT <reciever service port>
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.
I’m Bobby Curtis and I’m just your normal average guy who has been working in the technology field for awhile (started when I was 18 with the US Army). The goal of this blog has changed a bit over the years. Initially, it was a general blog where I wrote thoughts down. Then it changed to focus on the Oracle Database, Oracle Enterprise Manager, and eventually Oracle GoldenGate.
If you want to follow me on a more timely manner, I can be followed on twitter at @dbasolved or on LinkedIn under “Bobby Curtis MBA”.