Q: i SeriesのIBM DB2からMySQLへ「continuous mirroring」モードでレプリケーションを設定したとします。ソース・テーブルも正確にジャーナルされています。レプリケーションに指定されたテーブルは使用頻度が高いです。毎分100テーブル以上がアップデート、インサート、削除されます。
レプリケーションの設定で、イニシャル・レフレッシュの「スタート時間（start time）」及びジャーナルの「トランザクション・リード・ポイント（transaction read point）」を指定します。レプリケーションがスタートした時、リフレッシュが約2時間稼働します。この時間帯で、多くのデータ変更がソース・テーブルで起こります。リフレッシュが終了し、「continuous mirroring」がスタートし、レプリケーション・コンフィグレーションで指定したジャーナル・リードポイントをベースにしてすべてのジャーナル変更が次に処理されます。
DBMotoはレフレッシュが行われている間に起こったデータ変更をどのように処理しますか？
A: ミラーリング・モードでレプリケーションのリフレッシュがスタートする前にDBMotoはトランザクション・ログから最後のIDをリードします。例えばそれを「LIDStart」とします。リフレッシュがスタートします。すべてのターゲット・レコードが削除され、replication propertiesで指定された設定（アイソレーション・レベルを含んで）を使用してすべてのソース・レコードがターゲット・テーブルにコピーされます。このオペレーションの間でトランザクションが起こった場合、リフレッシュでキャッチされるものも、されないものもあります。これはサブミットされた時間、どのレコードが影響されたか、テーブルにインデックスがあるか、アイソレーション・レベルなどの多くのファクターに依存します。
リフレッシュが終了した時にDBMotoはログから最後のトランザクションIDをリードし、トランザクションIDの「LIDStart + 1」から最初のミラーリング・インターバルをスタートさせます。LIDStart と LIDEnd 間のすべてのトランザクションは通常とは違って管理されます。それはレフレッシュですでに処理されているかもしれません。DBMotoは不正確なエラー出力を避けるために、この間隔でのすべての各トランザクションを検証します。例えばINSERTトランザクションではDBMotoはインサートを行おうとする前に最初にレコードが存在するかどうかを検証します。もしレコードが存在すればDBMotoはリフレッシュでレコードが既に処理されたとして、トランザクションを無視します。
—————– 原文 —————————–
Q: Assume that you are setting up a replication in “continuous mirroring” mode from IBM DB2 on 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 DBMoto handle the data changes which occur while the refresh is taking place?
A: Before starting the refresh of a replication in mirroring mode, 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, 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. DBMoto verifies every single transaction in this interval to avoid reporting incorrect errors. For example, for an INSERT transaction, DBMoto first verifies if the record exists before trying to insert it. If the record exists, DBMoto ignores the transaction assuming that it has already been processed by the refresh.
「Synchronizing Refresh and Mirroring when Doing an Initial Refresh」
Product: DBMoto
Version: DBMoto 5 or above
Category: Replication
Last Updated: 05/15/08
Topic ID: KBFAQ 1601
Summary: Managing transactions with Refresh and Mirroring when doing an Initial Refresh
関連したトピックス
- レプリケーションの設定【リアルタイムレプリケーションツールDBMoto】
- ミラーリングの復旧で、リフレッシュ後の開始でエラー【リアルタイムレプリケーションツールDBMoto】
- レプリケーション設定手順（各DB別）【リアルタイムレプリケーションツールDBMoto】
- Oracle Log Miner と Redo Logについて【リアルタイムレプリケーションツールDBMoto】
- Oracle Redo Log の Transaction ID取得に失敗する場合【リアルタイムレプリケーションツールDBMoto】
- Handling errors with SQL Serverについて【リアルタイムレプリケーションツールDBMoto】
- シンクロナイゼーションについて【リアルタイムレプリケーションツールDBMoto】
- レコード登録・更新処理に対するコミット・タイミング処理【リアルタイムレプリケーションツールDBMoto】
- パフォーマンスを確認するレプリケーションアクティビティビューア【リアルタイムレプリケーションツールDBMoto】
- __DBM__MASTERLOG / _DBM_LOG_xx のテーブルについて【リアルタイムレプリケーションツールDBMoto】
RSSフィードを取得する
