Oracle Golden Gate dual-active replication to avoid repeated replication Parameters

I will briefly describe some practical and common parameters of goldengate.

1. Parameters for Bidirectional replication to avoid circular Data Replication

First, describe circular replication, which is described on the official website:

In a bidirectional configuration, SQL change s that are replicated from one system
Another must be prevented from being replicat ed back to the first system. Otherwise, it
Moves back and forth in an endless loop, as in this example:
1. A user application updates a row on system.
2. Extract extracts the row on system A and sends it to system B.
3. Replicat updates the row on system B.
4. Extract extracts the row on system B and sends it back to system.
5. The row is applied on system A (for the second time ).
6. This loop continues endlessly.
To prevent data loopback, you may need to provide instructions that:
● Prevent the capture of SQL operations that are generated by Replicat, but enable
Capture of SQL operations that are generated by business applications if they contain
Objects that are specified in the Extract parameter file.
● Identify local Replicat transactions, in or der for the Extract process to ignore them.

Translation: changes made to data on the master end are applied to the slave end. However, when the data transferred from the master end changes, the slave end is also affected by the extract process.
And returns the results to the master end. Then the master end is assigned to the slave end, which forms a circular replication, which will keep repeating.

Be sure to understand the cause: the user who executes data modification on the master end is the user corresponding to the business application (not the ogg user), but the slave end passes the modification on the execution master end.
The user who modifies the data is the ogg copy user, that is, the ogg user I configured earlier. (Ogg schema) and the data modification initiated by this user
It is only an application on the master side, but a transaction on the master side. Instead, the data cannot be modified and returned to the master end. Therefore, add parameters to the parameter file.
Filter out the data modifications initiated by this user.

Taking the oralce database as an example, the parameters are described as follows:

Do either of the following to specify the Replicat database us er. All transactions generated
By this user will be excluded from being captured. This information is available to Extract
In the transaction record.
● Identify the Replicat database user by name with the following parameter statement
In the Extract parameter file.
Tranlogoptions excludeuser <user name>

This parameter is added to the extract parameter file on the master and slave ends.

For example:

USERID ogg, PASSWORD aacaaaaaaaaadahbldcciioirfnepb, ENCRYPTKEY default
Tranlogoptions excludeuser ogg

The key to understanding this problem is to clarify the user. This is the key step for configuring active-active standbys.