こんにちは、エンジニアの宮本です。

CData Sync を使って「 DB のレコードを別の DB にレプリケートしたい」というお話を、問合せやイベント時などで受けることがあります。
CData Sync は SaaS データ以外にも、DB をデータソースとして扱うことができるため、DB → DB の連携が可能です。

また、CData Sync 最新機能では、レプリケート先テーブルへのマッピングを GUI 上で設定することができるため、既存テーブルへ別なデータソースのデータを追加していくことができます。

今回は、既存テーブルへのマッピングを交えながら、SQLServer → PostgreSQL への連携を行う方法をご紹介します。

構成

最初のポンチ絵のとおり、SQLServer から PostgreSQL の間に CData Sync が入り、データ連携を行うようになります。
やりたいことは、PostgreSQL に事前にテーブルを用意しておき、SQLServer から PostgreSQL へある特定のカラムのみを連携するジョブを実行します。

※CData Sync のインストールおよび基本的な操作は、以下の記事を参照いただければと思います。

https://jp.cdata.com/blog/2019-12-02-160226

既存テーブルへのレプリケート

レプリケート前のテーブル内容確認

レプリケート前にデータソース、レプリケート先のテーブル定義とレコードを確認してみます。

PostgreSQL のテーブル

PostgreSQL には以下の内容でテーブル＆レコードが存在しています。
テーブル名：Customer

レコード

SQLServer のテーブル

テーブル名：Account

ID と NAME だけをレプリケートするジョブの作成

SQLServer の ID と NAME 項目のみを連携するジョブを作成してみます。
データソースにSQLServer、Destination に PostgreSQL を設定した後、「テーブルを追加」からAccount テーブルを選択します。

次に自動生成された赤枠のクエリをクリックしてください。

ここでは、レプリケート先のテーブルを新規作成するか既存テーブルを使うかを選択することができますので、「既存のテーブルにマップ」を選択します。

既存テーブルとして Customer テーブルを使いますので、選択してOKボタンをクリックします。

次に「カラムマッピング」タブを選択し、マッピングを行っていきます。データソースと同期先カラムが表示されますが、既存テーブルのカラムとデータソースのカラム全てが含まれて表示されています。

今回必要なカラムは赤枠部分のみなので、不要カラムは連携しないよう設定します。真ん中の赤枠部分にカーソルを当てると、矢印が表示されている場合はバツ印が表示されますので、バツ印を選択し連携対象から外していきます。

不要な連携を解除すると以下のように Email だけの連携になってしまいます。
Id にも SQLServer のカラムを設定するために、カラム名に表示されている「Select...」をクリックし、対象のカラムを選択します。

これで実行したいクエリが作成できました。

ジョブ実行

早速実行していきます。チェックボックスにチェックを入れ「実行」ボタンをクリックします。

正常に完了したメッセージが表示され、5件が連携されたことがわかりました。

レコードを確認

SQLServer にあった5件のレコードが、PostgreSQL の Customer テーブルの Id と Email だけに連携されているか確認してみます。 指定した通りのレコードが連携されています。

レプリケート項目を１つ追加

SQLServer で保持している更新日付を連携してみます。設定は以下の赤枠のように対象のカラムを選択するだけです。

実行すると SQLServer のレコードを再度登録しなおすため、先ほどのジョブの結果に加えて、更新日付が追加された内容が連携されてきます。

想定通り、更新日付部分だけ連携されています。

※SQLServer は差分更新の対象ではないため、ジョブ実行のたびに全件入れなおす仕様となっております。

データソース側のデータを修正した場合

次に SQLServer のデータを修正した場合、正しく反映されるか確認します。
といっても先ほどお伝えしましたが、ジョブ実行のたびに全件入れ直しているため、修正したレコードも連携されるようになります。

今回は1箇所だけ更新してみました。

では先ほど作成したジョブを再度実行し、PostgreSQL のテーブルを確認すると、変更したデータが正しく連携されていることが確認できました。

データソース側のデータを削除した場合

次は削除を確認してみます。まずは先ほど Email を更新したレコードを削除して、SQLServer の件数を4件にしてみます。 その後、ジョブを実行します。

ジョブを実行すると、4件のレコードが連携されました。

連携内容を確認するために PostgreSQL を確認してみると、SQLServer 側で削除されたレコードが残ったままでした。

これは以下のイメージを参考にしてください。レコード２～５は連携されてくるので、上書きされますが、データソース側で削除されたレコードは連携されなくなるので、DB に削除データがそのまま存在し続けてしまうことで起きています。

テーブルの削除

データソース側と完全に同期したい場合は、オプションで「テーブルを削除」もしくは「テーブルデータの削除」を設定してください。これを選択することによって、ジョブ実行前にレプリケート先のテーブルを削除し、ジョブ実行ごとにテーブルを作成していきます。そのため、レコード自体も最初から登録されていくので削除データは含まれないようになります。

CheckCache コマンド

カラムがデータソースとレプリケート先で一致する場合は、データを削除することができます。では、以下の SQLServer の Shipments というテーブルをそのまま連携します。

Shipments というテーブルで PostgreSQL に3件レプリケートされました。

PostgreSQL の内容

ここで SQLServer のレコードを1件削除し、2件にしてみました。

このまま、最初に実行した以下のジョブを実行してしまうと、先ほどと同じように削除データが存在したままになってしまいます。

そこで、最新の CData Sync では、CheckCache コマンドというものが使えるようになりました。CheckCache はデータソースとレプリケート先の両方を照会し、レプリケート先に過不足があった場合は、データソース側に合わせるような処理を行ってくれます。

構文は以下のようになります。

では以下のジョブを実行してみます。実行前の時点で SQLServer のレコードは2件、PostgreSQL は3件となります。

1件の処理を行ったと Status に表示されました。

PostgreSQL を確認すると確かに SQLServer で削除したレコードが、PostgreSQL でも削除されていることが確認できました。

最後に

新機能を交えながらの DB から DB への連携をご紹介しました。 CData Sync は30日間の評価版がありますので、SaaS → DB や DB → ファイルなど、色々な組み合わせでお試しください。