Q1)ほぼ同時に同一データに更新があった場合、どうなるのか?
その回避策は?”
A1)DBMoto で Synchronization 時にデータ更新のコンフリクト(*1)が発生した場
合の対応方法としては以下の4種類が用意されています。
1. SourceServerWins :ソース側の更新内容でターゲット側を更新します。
(デフォルト)
2. TargetServerWins :ターゲット側の更新内容でソース側を更新します。
3. FirstComeWins :タイムスタンプの早いものの内容で両テーブルを更新
4. Use Script :DBMotoはイベントを作成するのでユーザーはスクリプ
トで行いたい処理を記述する
(*1) データ更新のコンフリクト
DBMoto はリプリケーションに定義されたインターバルでトランザクションロ
グを読み更新を行います。同一インターバルでソースとターゲットが同一レコー
ドに対して異なる更新が行われていた場合をデータ更新のコンフリクトとみなし
ます。
2つの更新が別のインターバルに入ればOKケースの動作になります。
NGケースのような結果になることはどの設定でもございませんが、
コンフリクトが発生した場合にはテーブルの同一性を保障するために
1~3の設定ではどちらかのトランザクションが捨てられる動作となります。
Q2)スキーマ単位やテーブル単位での単方向レプリケーションは可能か?
A2)テーブル単位のリプリケーションは可能です。
スキーマ単位という定義はありませんが、複数のリプリケーションを作成する
ためのウィザードが用意されています。
Q3)片側で障害が発生した場合に必要なオペレーションは?
A3)短時間の障害であれば接続が復旧し次第リプリケーションが再開されます。
障害のための停止期間が長引き停止期間のトランザクションがトランザク
ションログから消えてしまった場合には、initial refresh (テーブルの
フルコピー) が必要になります。initial refresh には時間が掛かることが
予想されますので、refresh 完了まではどちらの系でも更新を行わないこと
が推奨されます。(refresh中のトランザクションログあふれが懸念されるため)
注意点としては、DBMoto は Refresh を常に ソース→ターゲット という方向
で行います。ソース側DBが障害を起こしその間ターゲット側で更新を行ってい
た場合そのまま refresh を行うとターゲット側の更新内容が消えてしまいま
す。
この場合、ソースとターゲットを逆にした新たなリプリケーションを定義す
る必要があります。
関連したトピックス
- シンクロナイゼーションにおけるコンフリクト回避について【リアルタイムレプリケーションツールDBMoto】
- ミラーリングの復旧で、リフレッシュ後の開始でエラー【リアルタイムレプリケーションツールDBMoto】
- DBMoto5 FAQ: 2006-7【リアルタイムレプリケーションツールDBMoto】
- イニシャル・リフレッシュを行った時のリフレッシュとミラーリングでのトランザクション管理【DBMoto】
- レコード登録・更新処理に対するコミット・タイミング処理【リアルタイムレプリケーションツールDBMoto】
- DBMotoユーザ事例:ASL Modena
- 複数の複製元サーバから1つの複製先サーバへの結合レプリケーションもDBMotoで簡単実現
- グループレプリケーションにおける同時DBトランザクションの対策【リアルタイムレプリケーションDBMoto】
- Oracleをmirroringモードで使う場合【リアルタイムレプリケーションツールDBMoto】
- リフレッシュモード時のSQL Filter の記載方法【リアルタイムレプリケーションツールDBMoto】