各製品の資料を入手。
詳細はこちら →
PostgreSQLにある既存テーブルへSQLServerのデータを連携してみる：CData Sync
こんにちは、エンジニアの宮本です。
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://www.cdata.com/jp/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 → ファイルなど、色々な組み合わせでお試しください。
