Dockerized GoldenGate Replication to the Cloud

Yvan Florian
7 min readDec 5, 2020

For some reason, I needed to establish a replication between a dockerized oracle database container running on my local machine and my always-free oracle cloud free tier. To keep it all in docker was my end-goal–even goldengate. However, I ended up taking more time than I thought and so decided to write the process down, step-by-step.

Since this was for POC purposes, I used the most basic configurations. The OGG architecture used here is the classic one (I do intend to explore a dockerized microservices architecture environment and possibly post an article on how to set it up).

The first thing to do is to download these docker images here. Here is then what follows.

Build the Base Image

To build the base Image, one needs to download below 3 files. This assumes by default the version 12.2.0.1. You can change it by following these instructions:

  1. oracle-instantclient12.2-basic-12.2.0.1.0–1.x86_64.rpm
  2. oracle-instantclient12.2-devel-12.2.0.1.0–1.x86_64.rpm
  3. oracle-instantclient12.2-sqlplus-12.2.0.1.0–1.x86_64.rpm

After download:

  • Paste the above three files in the folder ~\docker-images-master/OracleInstantClient/dockerfiles/12.2.0.1.
  • After this, run this command: docker build --pull -t oracle/instantclient:12.2.0.1 .
  • Depending on your setup, you might be prompted to do a docker login in which case, if you have an valid account you can login by issuing docker login container-registry.oracle.com and run the previous “docker build” statement (create an account, if you don’t).

If the previous command is working, you shall see a screen like below

It will run for a bit; but for us we are on the look-out for below success message:

Build the Golden-Gate Image

To do that,

  • Download OGG. I downloaded Oracle GoldenGate 19.1.0.0.4 for Oracle on Linux x86–64, found here
  • For this step, these 2 files are key:
  • Now that everything is in place, we can start building the image with ./dockerBuild.sh 191004_fbo_ggs_Linux_x64_shiphome.zip
  • Building the image will take some time. We’ll be looking out for this success message. And if I run the list of my images, I will see that I have oracle/goldengate-standard in the my docker images list.
  • After this we know that the Image was built successfully. Run the image by issuing this command docker run -d -it -p 32713:7809/tcp --name goldengate oracle/goldengate-standard:19.1.0.0.4 It will start the container and I will get below among the list all my containers using docker -ps a ( I formatted my output to only print out the container, status and the names and filter only running containers. More info, in the docker CLI Reference)
  • Now, let’s SSH into the container by issuing docker exec -it goldengate bash followed immediately by the command ls to list items in the directory(as a way to test if it is working). Note that it is very important to attach the shell in the container as the user “Oracle”
  • After that we can safely run goldengate’s ggsci and it will display this
  • Now OGG is ready for setup

OGG Setup & Configuration

As I am running a dockerized multi-tenant oracle database container, the only way to get OGG Running is to configure the GoldenGate Capture in Integrated mode, at the root level. So let’s configure it.
First, we need to know that the dockerized database container is part of a bridge network, which, on my machine, is called ‘oracle_network’. In order for these 2 containers to be able to communicate, I will have to add the new container in the bridge-network. So I have to issue a command like this:

  • After that, we can issue this command, to inspect our networks: docker network inspect oracle_network. We are on the look-out for this:
  • When this is done, we’re good to go. We start by issuing, inside the goldengate container, the ggsci command to create a credentialstore
  • Afterwards, we add an entry in credential store by issuing the following command
  • With this in place, we can create one extract by first issuing the edit param command (which will open vim editor) and add below configurations
  • The process must be registered, as below
  • We then now add it as an integrated process as below and set it to begin reading database changes right away. The third command will show me that the process is running without problem
  • In few seconds the status of e_ref will switch to ABENDED. The reason is that we did not add exttrail
  • Then, now that the extract is running, we need to add a pump. The same way we created the extract is how we’re going to do it. First adding parameters:
  • Then adding the actual extract process
  • Adding the remote trail, then starting the process. You’ll then see the process running.
  • We now need to turn to the cloud instance for the replicat process. To be able to connect to the oracle cloud database(ADB: Autonomous Database, as I will hereby refer it to), one needs to download the DB Wallet for the client. Here, after login to the cloud, is how I did it with my transaction processing DB Instance. I click on the “DB Connection” and in the pop-up window which will come as a result, click on the “Download Wallet”.
  • Now, we need to make sure we create a “network” folder inside your golden-gate container. The default directory would be /usr/lib/oracle/12.2/client64/lib.
  • Create a new folder “admin” inside the newly created directory “network”
  • Unzip the downloaded wallet from the cloud. On my side, I did a bit of customization: I created inside the downloaded folder, a subdirectory(and called it “adw”, for absolutely no reason) where I move all files and remain with only these 2 files: tnsnames.ora and sqlnet.ora
  • We can now move the unzipped folder inside your golden-gate container. You can use this docker command: docker cp [path on your local machine] goldengate:/usr/lib/oracle/12.2/client64/lib/network/admin
  • The directory inside my goldengate image will look like below.
  • With the above understanding of my folder structure, the last thing here is we go back to the “admin” directory and change sqlnet.ora to have the path of the wallet in its settings
  • Now, with this done, we test the connection to ADB in SQLPlus like below.
  • Great! We’re now ready to go back to goldengate settings.
  • We’re now remaining with just configuring the replicat process. Let’s first create the parameters:
  • Then we add and start the process with this command: add replicat r_cloud, nodbcheckpoint, exttrail ./dirdat/rp
  • You should see it now running

That’s it any update on the table in the local db will replicate in the cloud instance. Sooo, happy replication…

--

--