Active/Active replication is the process of keeping two or more live databases in-sync with each other and is used for high availability, load balancing and performance. The simplest example would be two databases, one maintained on System A and a second on System B. All changes made to the database on System A must also be applied to the database on System B, while at the same time, all changes made to the database on system B must be replicated to System A.
Historically Active/Active replication could only be accomplished by the primary database manager be it IMS, Db2 or Oracle using shared memory to manage concurrent updates. The fundamental issue with that approach is the latency introduced as the physical distance between the two replicated databases increased. With Connect CDC (SQData), an Active/Active replication architecture can be implemented that is unaffected by distance.
The first challenge is to ensure that the replication architecture itself, does not create cyclic update transactions, where the updates being replicated from System A to System B are incorrectly replicated back from System B to System A. To address this problem, Connect CDC (SQData) uses information in the log to identify the source of the update. In the case of Db2, the Capture Agent generally uses the Db2 Plan used by the Apply Engine. Alternatively the Db2 User or correlation-ID under which each transaction was applied to exclude from capture those transactions applied by the resident Engine. In the case of the Oracle Log Miner Capture, the User-ID is used and for this reason it is suggested that a dedicated User-ID is assigned to the replication Engine. This User should not used by any program, application, or user making changes to the database that need to be replicated. This includes other Connect CDC SQData components and manual edits to the database.
The second challenge is handling concurrency issues which arise from updates being applied to the same data on multiple machines and/or delays in replication from one system to another. In our example this would occur if a specific record was altered on System A and then altered again on System B before the change from System A is replicated to system B. These issues can be addressed by a variety of techniques, but they generally fall into two classes: Avoidance and Detection.
The most common Avoidance strategy involves some form of transaction affinity within the application, routing the transaction to a specific server based on key range, geographic location, etc. Applications that update subsets of data on only a single system ensure that data is only replicated outward from the original source. In effect, making the replicated data, read-only on the other systems.
Connect CDC (SQData) will detect out of sync conditions that have occurred due to issues outside of its control. The replication Engine by default is configured to compensate changes by converting updates to inserts (if the record does not exist in the target), inserts to updates (if the record already exists in the target) and to drop deletes (if the record does not exist in the target). The Engine can also be configured to do other things in response to these events, including termination of replication, exception processing or only exception reporting.
Connect CDC (SQData) also can also detect and compensate if the engine is attempting to update newer data with older data. This can be accomplished by a SmartApply technique utilizing an Connect CDC SQData managed time-stamp column added to each table. SmartApply can also be very useful when used to re-sync out-of-sync databases by re-capturing data from a point-in-time when the databases were known to be in a consistent state.
Finally, Connect CDC (SQData) can also detect unintended activity, such as, an incomplete transaction affinity model or fraudulent transactions which are designed to exploit the time it takes to sync a transaction. Near Real time replication is the best defense for closing this window, however Connect CDC (SQData) can monitor for such activity. This is accomplished by comparing the before image of the replicated data to the data in the target. If they match, then the record in the target has not been altered since the transaction was initiated.
Visit Precisely https://www.precisely.com/support before implementing an Active/Active replication architecture to ensure that all factors impacting its effectiveness are addressed.