DBMotoはDB2/400(DB2 for IBM i)<=>DB2/400間でのミラーリング(片方向レプリケーション)とシンクロナイゼーション(双方向レプリケーション)の両方をサポートします。
ここでは、DB2/400<=>DB2/400間でのシンクロナイゼーション(双方向レプリケーション)で何も更新を行わなわず、「Idol」状態に戻ってしまう問題について説明します。
【環境】
SourceDB :DB2/400(AS400)
TargetDB :DB2/400(AS400)
InitialRefresh:あり
更新レコード数 :10000件
【状況】
:InitialRefresh完了後、Source及びTargetに更新を行う。
statusに「Mirroring」の表示がされるが、何も更新を行わなわず、「Idol」状態に戻る。以降もシンクロナイゼーションが行われない。
【原因と解決策】
Source(またはTarget)のユーザーが、自分自身に対して更新を行ったために発生。
シンクロナイゼーションモードでは、SourceとTarget間で行われる更新で無限ループ(更新に対する更新)が発生しない様、DBのアクセスユーザーを使用して他との更新の
区別を行っている。そのため更新を行うユーザーを別途用意する必要がある。
(注)AS/400(またはSystem i)では、そのシステムの中核部分に、RDBMSの機能を統合されていてDB2/400と名付けられた。DB2/400は、現在ではDB2 for IBM iという名称で呼ばれることが多い。
関連したトピックス
- SourceとTarget等の設定について【リアルタイムレプリケーションツールDBMoto】
- イニシャル・リフレッシュを行った時のリフレッシュとミラーリングでのトランザクション管理【DBMoto】
- MySQLでのutf8で文字化けの対応方法【リアルタイムレプリケーションツールDBMoto】
- Oracle DB起動時にエラーORA-00257が出て起動しない際の対処法
- Database Performance Analyzer (旧Ignite)の情報からメモリのチューニング【DBの監視・管理】
- DBMotoサイドでPrimary Keyを設定した場合のミラーリング(SQL Server)【リアルタイムレプリケーション】
- シンクロナイゼーションで双方の同じレコードを修正した場合【リアルタイムレプリケーションツールDBMoto】
- ミラーリングの復旧で、リフレッシュ後の開始でエラー【リアルタイムレプリケーションツールDBMoto】
- GlueSyncがAWS S3(互換も含む)に対応:分析、データレイク、コールドストレージ向けに、AWS S3 へのリアルタイムデータレプリケーションがシンプルに
- GlueSyncでNoSQL活用を加速:データモデリング編