Implementing the GI Standalone Agent for Oracle Goldengate

In my previous post, we discussed configuring multi-master replication in a clustered environment.  In this post, we will discuss configuring and using the standalone agent to manage the Goldengate processes using a virtual IP (VIP).

The first step is to remove the current agent configuration. The command to do this is:

$ggclust11 agctl remove goldengate GG_SOURCE

$ggclust21 agctl remove goldengate GG_TARGET

We will create a virtual IP that the Goldengate processes will use. The pump processes will modified to connect to this VIP to transmit data to the replicat process.

In order to create the VIP, we first must determine the correct network.  It must be on the same network as the Virtual IPs and SCAN IPs for the database. The command below will show the correct network to use, though most likely as a DBA you would already know this:

crsctl status resource -p -attr NAME,USR_ORA_SUBNET -w "TYPE = ora.network.type" |sort | uniq

NAME=ora.net1.network
USR_ORA_SUBNET=10.12.1.0

For this process, we have chosen 10.12.1.201 for the VIP for the ggclust11/12 cluster.  The name of this VIP is ggclust1-vip.

The VIP for the ggclust21/22 cluster is ggclust2-vip, 10.12.1.202.

In order to configure a VIP, the agctl command must be run as root.  In our previous example, the commands were run as Oracle. The commands below were run to configure the VIPs on the two clusters:

ggclust11 # cd /u01/app/oracle/xag/bin

ggclust11 # ./agctl add goldengate GG_SOURCE \
--gg_home /u02/gghome \
--oracle_home /u01/app/oracle/product/19.3.0/dbhome_1 \
--db_services ora.demogg1.oggserv.svc --use_local_services \
--monitor_extracts hrext1,hrpump --monitor_replicats hrrep2 --filesystems ora.acfs.ggvol.acfs \
--network 1 \
--ip 10.12.1.201 --user oracle --group oinstall \
--nodes ggclust11,ggclust12

ggclust21 # cd /u01/app/oracle/xag/bin

ggclust21 # 

./agctl add goldengate GG_TARGET \
--gg_home /u02/gghome \
 --oracle_home /u01/app/oracle/product/19.3.0/dbhome_1 \
 --db_services ora.demogg2.oggserv.svc --use_local_services \
 --network 1 \
 --ip 10.12.1.202 \
 --monitor_extracts hr2ext1,hrpump2 --monitor_replicats hrrep1 --filesystems ora.acfs.ggdata.acfs \
 --user oracle --group oinstall \
 --nodes ggclust21,ggclust22

Next modify the parameter file for the pump (hrpump and hrpump2) process so that the remotehost line points to the newly created VIP.

For hrext1:

rmthost ggclust2-vip, mgrport 7809

For hr2ext1:

rmthost ggclust1-vip, mgrport 7809

Finally, start the goldengate replication on both clusters:

ggclust11$ agctl start goldengate GG_SOURCE

ggclust12$ agctl start goldengate GG_TARGET

At this point, if you want to relocate the replication, you can use the ‘agctl relocate goldengate’ command, for example:

agctl relocate goldengate GG_SOURCE –node ggclust12

Note that since you are moving the VIP each time you do this, the pump processes will abend.  You will either need to restart the pump processes manually, or configure them for autorestart. (AUTORESTART EXTRACT HRPUMP in the file mgr.prm).

To stop the processes, run the stop command:

agctl stop goldengate GG_SOURCE

To check the status of the Goldengate processes:

agctl status goldengate GG_SOURCE

At this point you have configured the most basic high availability for Goldengate in a cluster.  You will need to add monitoring scripts and options processes for when Goldengate runs into problems.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: