| Product: | Syniti Data Replication/DBMoto |
| Version: | All |
| ID: | 1601 |
| Summary: | Managing transactions with Refresh and Mirroring when doing an Initial Refresh |
Q: Assume that you are setting up a replication in "continuous mirroring" mode from IBM Db2 for i to MySQL. The source table is correctly journaled. The table designated for replication is highly used. There are over 100 updates, inserts and deletes per minute.
In setting up the replication, you specify the "start time" of the initial refresh AND the "transaction read point" of the journal. When the replication starts, the refresh runs for perhaps 2 hours. During this time, many data changes occur on the source table. After the refresh is finished, the "continuous mirroring" starts, so all journaled changes based on the journal readpoint specified in the replication configuration are now processed.
How does Syniti DR/DBMoto handle the data changes which occur while the refresh is taking place?
A: Before starting the refresh of a replication in mirroring mode, Syniti DR/DBMoto reads the last ID from the transaction log, let's call it LIDStart. Then the refresh starts: all the target records are deleted and all the source records are copied to the target table using the settings (isolation level included) specified in the replication properties. If transactions came in during this operation they may or may not be caught by the refresh. This depends on many factors: the time they are submitted, which records are affected, if there are indexes on the table, the isolation level, and so on.
When the refresh ends, Syniti DR/DBMoto reads the last transaction ID (LIDEnd) from the log and starts the first mirroring interval from the transaction ID LIDStart + 1. All the transactions between LIDStart and LIDEnd are managed differently from usual since they could have already been processed by the refresh. Syniti DR/DBMoto verifies every single transaction in this interval to avoid reporting incorrect errors. For example, for an INSERT transaction, Syniti DR/DBMoto first verifies if the record exists before trying to insert it. If the record exists, Syniti DR/DBMoto ignores the transaction assuming that it has already been processed by the refresh.