「Oracle Golden Gateを使ってみた」 応用編の2回目、今回でOGGの検証は最後になります。
前回、マニュアルのサンプル通りに設定した所、レプリケート元と先でデータが異なる結果となってしまいました。
なので今回はレプリケート元と先でデータの差分が出ない設定を試してみます。
前回の設定で差分が出てしまうのは、updateとdeleteが競合したケースになります。
なのでその二つについては優先DBを決めて、優先側の更新は相手側で上書きし、逆は無視します。
レプリケート元を優先DBとしてテストします。
REPLICATパラメータのMAP文のみを抜粋すると、以下の様になります。
レプリケート元
MAP ggtest.TAB3_2, TARGET ggtest.TAB3_2, MAPINVISIBLECOLUMNS,
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL),
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (CDRTS$ROW))),
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (CDRTS$ROW))),
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, DISCARD)),
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, DISCARD)),
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD));
レプリケート先
MAP ggtest.TAB3_2, TARGET ggtest.TAB3_2, MAPINVISIBLECOLUMNS,
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL),
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (CDRTS$ROW))),
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (CDRTS$ROW))),
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)),
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)),
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD));
updateとdeleteをそれぞれ実行します。
レプリケート元
SQL> update TAB3_2 set col3='ggs' where col1=1;
1行が更新されました。
SQL> commit;
コミットが完了しました。
SQL> select * from TAB3_2 order by 1;
COL1 COL2 COL3
---------- ---------------------------------------- --------------------
1 22-03-29 11:06:50.584181 ggs
レプリケート先
SQL> delete from TAB3_2;
1行が削除されました。
SQL> commit;
コミットが完了しました。
SQL> select * from TAB3_2 order by 1;
レコードが選択されませんでした。
一定時間経過後。
レプリケート元
SQL> select * from TAB3_2 order by 1;
COL1 COL2 COL3
---------- ---------------------------------------- --------------------
1 22-03-29 11:06:50.584181 ggs
レプリケート先
SQL> select * from TAB3_2 order by 1;
COL1 COL2 COL3
---------- ---------------------------------------- --------------------
1 22-03-29 11:06:50.584181 ggs
これでデータの不一致は起きなくなりましたが、非優先DB側のdeleteは無かった事にされてしまいました。
updateしたデータが消えるのは、update後に後続セッションから削除された時と同じなので違和感ないのですが、deleteした筈のデータが相手側のupdate(insertではなく)で復活してしまうのは何となく感覚的に変な気がします。
※あくまで私の感覚で「変」なだけですが…
なのでDELETEROWEXISTSの設定を変えてデータの不一致もdeleteした行が復活する事もなるべく起きなくなるように出来ないかと色々試してみましたが、却って不一致が広がるだけでした…
マニュアルに載っていた例は単なる例ではなく、それが一番無難な解決方法なのかも知れません。
尚、設定はテーブル単位またはスキーマ単位でできるので、優先DBを設定して運用上問題がなければ、今回の設定方式も良いと思います。
