こんにちは、エンジニアの宮本です。
CData Sync を使って「 DB のレコードを別の DB にレプリケートしたい」というお話を、問合せやイベント時などで受けることがあります。
CData Sync は SaaS データ以外にも、DB をデータソースとして扱うことができるため、DB → DB の連携が可能です。
また、CData Sync 最新機能では、レプリケート先テーブルへのマッピングを GUI 上で設定することができるため、既存テーブルへ別なデータソースのデータを追加していくことができます。
今回は、既存テーブルへのマッピングを交えながら、SQLServer → PostgreSQL への連携を行う方法をご紹介します。
構成
最初のポンチ絵のとおり、SQLServer から PostgreSQL の間に CData Sync が入り、データ連携を行うようになります。
やりたいことは、PostgreSQL に事前にテーブルを用意しておき、SQLServer から PostgreSQL へある特定のカラムのみを連携するジョブを実行します。
※CData Sync のインストールおよび基本的な操作は、以下の記事を参照いただければと思います。
既存テーブルへのレプリケート
レプリケート前のテーブル内容確認
レプリケート前にデータソース、レプリケート先のテーブル定義とレコードを確認してみます。
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 → ファイルなど、色々な組み合わせでお試しください。
