This blog explores the key features of extended replication environments, specifically those utilizing Bi-Directional with Replication Tags. I’ll provide an example of how-to setup Bi-Directional Replication and guide you through the role of Replication Tags. Note that parameters GETREPLICATES/GETAPPLOPS and IGNOREREPLICATES/IGNOREAPPLOPS are not needed anymore and are desupported in GoldenGate 23ai.

How to set up Bi-Directional Replication?

In a Bi-Directional replication setup, changes are synchronized between two databases in both directions. Configuring Bi-Directional Replication is like setting up two Uni-Directional environments. First, you establish replication from one side (North) to the other (South). Then, you configure replication in the opposite direction, from South back to North.

Blue arrows pointing to the left Description automatically generated

Now, you also need to think about looping prevention: Without loop prevention, changes could cycle back and forth between the databases, where a change sent to the target would get replicated back to the original database, repeating the process. Loop prevention in Oracle Databases is managed through Replication Tags. In a Bi-Directional Replication set up, the only aspect you must consider is within the Extract parameter files:


EXTRACT extn

USERIDALIAS ggnorth
EXTTRAIL north/ea
TRANLOGOPTIONS EXCLUDETAG +
DDL INCLUDE MAPPED
TABLE hr.*;


EXTRACT exts

USERIDALIAS ggsouth
EXTTRAIL south/ea
TRANLOGOPTIONS EXCLUDETAG +
DDL INCLUDE MAPPED
TABLE hr.*;


Other than that, there is no change. The Distpaths and Replicats remains the same.

Engineers who have worked with GoldenGate for an extended period used the EXCLUDEUSER or EXCLUDEUSERID options to filter out changes made by the Database Administration user (GGADMIN). This allowed them to differentiate between changes made by the Replicat user (GGADMIN) and those made by application users (non-GGADMIN). While this functionality still works, it’s not the most modern approach. Instead, use Replication tags, as filtering operations are now based on these Replication tags rather than the user. Two sets of scripts will be provided shortly. One is using AdminClient commands to setup Bi-Directional Replication, the other script is directly using the underlying REST API commands using cURL.

In an Active-Active Bi-Directional Replication setup, it’s important to consider topics like Conflict Detection and Resolution. While I won’t be covering that in this blog, I reference an earlier post that addresses Automatic Conflict Detection and Resolution (Simplify Active-Active Replication with Auto-CDR).

Replication Tags – What happens behind the scenes?

Here is the explanation of how Replication works with Replication Tags within the Oracle Database:
Whenever the Replicat process writes changes to the database, it also uses a Replication tag within the Replicat session to mark this change. By default, this is a double-zero ('00') tag. When Extracts reads the changes from the transaction log (Redo or Archive log file), it can use this Replication tag to identify that the changes are originated by a Replicat process. With an TRANLOG EXCLUDETAG +, any tagged information will be filtered out by Extract.
Please not that the EXCLUDETAG and its counterpart INCLUDETAG are also available while adding a DistPath or as a Replicat parameter. Replication Tag-based filtering offers a whole new level of flexibility in filtering changes. You find more details about those parameters within the GoldenGate Reference Guide.

As previously noted, the Replicat assigns the tag within its session. There’s a useful trick you can take advantage of within your SQL database session to bypass changes in a Bi-Directional Replication. If you set a tag such as
 

SQL> EXEC DBMS_XSTREAM_ADM.SET_TAG('01')


you make this change only local to the Oracle Database as the tag ‘01‘ is also filtered out by Extract.

What is about GETREPLICATES/GETAPPLOPS and their counterparts IGNOREREPLICATES/IGNOREAPPLOPS?

With the use of Replication tags, you can distinguish changes made by the Replicat or the User Applications directly working on the Oracle Database. For this reason, there is no use of the parameters GETREPLICATES/GETAPPLOPS and IGNOREREPLICATES/IGNOREAPPLOPS and this is why those parameters are desupported from GoldenGate version 23ai onward.

Those parameters where intensively used for cascaded environments that I want to discuss in the next blog.