今回は CData Sync V23 に新しく追加された 変更データキャプチャ（CDC）利用時でのヒストリーモード機能についてご紹介します。
このヒストリーモードはこれまで Salesforce などの SaaS 系データソースでのみ利用できていたのですが、この度 RDB 系データソースでも利用できるようになりました。実際、RDB データソースでもヒストリーモードを使いたい！というリクエストは多くありましたので、そのリクエストの応えるべく CData Sync V23 にて対応いたしました。
ちなみにヒストリーモードとはデータソース側の変更履歴を同期先DBで保持できるような機能となりますが、詳しくは下記記事をご参照下さい。
CDC モード×ヒストリーモードとは
MySQL、PostgreSQL、SQLServer、Oracle といったRDB系データソース、かつ変更データキャプチャ（CDC）モードでのレプリケーションジョブの場合に、更新前のデータや削除したデータを同期先DBに履歴として残しておけるようになっています。
例えば基幹システムにある案件情報のステータスやアクティビティデータのトラッキングといったことが、ジョブオプションのON/OFFだけで実現できるようになります。
上のキャプチャの例では、ID=1 のNAME を変更した際の同期先DBのデータの持ち方を表しています。変更前データはActive という項目が0 になり、変更後のデータは追加で登録される仕組みとなります。
それでは実際の設定方法についてみていきましょう。
設定方法
まずはジョブ作成を行います。右上のジョブを追加から、ジョブ名、データソース、同期先を選択し、種類を変更データキャプチャに設定します。
変更データキャプチャについては下記記事にて各種設定記事のリンクが載っておりますのでご参考ください。
レプリケーションさせたいテーブルを選択します。今回は lead テーブルにしました。
次に高度な設定 タブ → 編集アイコンをクリックします。
ヒストリーモードのチェックボックスにチェックを入れて保存します。
以上で設定が完了です。
ジョブ実行
先ほど作成したタスクにチェックを入れ実行ボタンをクリックします。そうするとレプリケーション結果が表示されます。
以下は同期先の SQLServer の状態ですが、同期先テーブルに３つカラムが追加されていることが確認できました。
Start、Endはそのままですが、_cdatasync_active 項目は冒頭にお伝えしたActiveカラムになります。値が1 の場合は有効、0は変更前 or 削除済みデータとして保持され続けます。
では、データソース側の MySQL のデータに対して更新と削除を行ってみます。
まずは下記 SQL で更新したあと、改めて CData Sync のタスクを実行してみます。
UPDATE `cdata`.`lead` SET `Name` = 'cdatasync-historymode' WHERE (`Id` = '00Q0K000017XdxRUAS');
想定通り、変更されたレコード分の1件がレプリケーションされました。
SQL Server を見てみると、変更前のデータは_cdatasync_active = 0 で残るようになっていて、変更前後のデータがどちらも保持されていることが確認できました。
では最後にこのレコードをMySQL 側で削除してからもう一度タスクを実行してみると、削除レコード1件が同期先に連携されました。
SQL Server 上では、削除レコードは _cdatasync_active = 0 、加えて _cdatasync_end にMySQL 側で削除された日時が登録されていることが確認できました。
おわりに
いかがでしたでしょうか。見ていただいてようにジョブオプション１つで簡単に履歴管理ができるようになりました。
CData Sync V23 では今回ご紹介した機能以外にも多数アップデートされていますので、ぜひこの機会にお試しくださいませ。
関連コンテンツ
