マイグレーションの切り札、多機能データ同期ツール

SymmetricDS を使ってみましょう

2015-05-30JPUG PostgreSQL Unconference

高塚 遙 harukat@sraoss.co.jp

他DBMSからPostgreSQLにマイグレーションしていますか？

並行稼働したいんだよね。何か不安だし。 現システムはマ

テビューで連携しまくりですが

こういう要件に、皆様どうしていますか？

TOC

● SymmetricDS とは● アーキテクチャ● 基本的な使い方● 機能あれこれ● 実際の適用時の課題

SymmetricDSとは？

● open-source,● database independent,● data synchronization software● written in Java with Spring

Postgresinstance

SymmetricDS

SymmetricDS

Ora.instance

MariaDBinstance

HTTPJDBCJDBC

JDBC

SymmetricDS

HTTP

Ora.instance JDBC

since 2007

SymmetricDSとは (2)

● ほとんどの RDB に対応– トリガとJDBCがあれば

– mongoDB 連携– ファイル／

フォルダ同期

PostgreSQL / Greenplum / RedshiftSql Server / Sql Server AzureHSQLDB / H2 / Apache DerbyIBM DB2 / Interbase / InformixOracle database / MySQL / MariaDBFirebird / SQLiteSybase Adaptive Server EnterpriseSybase SQL Anywhere

SymmetricDSとは (3)

● 遅延型（非同期型）のロジカルレプリケータ● 任意テーブル間のデータ同期を実現

– 双方向データ同期が可能– カスケード構成が可能– N対１で行のマージ／パーティションが可能

● やりたければ N対Mでも

– トランザクション単位でのデータ同期● nontransactional も指定可能

アーキテクチャ (1)

(図は SymmetricDS User Guide より)

アーキテクチャ (2)

ユーザテーブル（元テーブル）

管理テーブルSYM_DATA

トリガ

更新内容を記録

アプリがデータ更新

SymmetricDS

管理テーブルSYM_OUTGOING_BATCH 他

バッチジョブを編成

管理テーブルSYM_INCOMING_BATCH 他

一時ファイル

バッチジョブを転送

ユーザテーブル（宛先テーブル）

バッチジョブを適用

SymmetricDS

基本的な使い方 (1)

● セットアップ手順– ノード毎にSymmetricDS用のユーザ／スキーマを用意

● 大まかには１ノードが１データベースと理解すれば良い

– インストール● unzip して置くだけ / Java 6 以上● ノード毎の接続設定ファイルを記述（engineファイル）

– ノード初期化● 最初のノードだけコマンド実行、SQL実行の手順がある● ２つ目ノード以降は自動で登録できる

基本的な使い方(2)

● 設定用管理テーブルの行で同期定義を記述する主な設定用管理テーブル 役割SYM_NODE ノードを定義SYM_NODE_GROUP ノードグループを定義SYM_NODE_GROUP_LINK グループ間の伝送方式を定義SYM_CHANNEL 同期のデータ転送を定義SYM_ROUTER 同期を定義（宛先とノード）SYM_TRIGGER 同期を定義（同期元）SYM_TRIGGER_ROUTER 上記２テーブルの組み合わせ

これらも自動で同期されるのでどれかのノードに設定すれば良い

基本的な使い方 (3)

● とりあえず簡単に設定するなら– SYM_CHANNEL は出来合いの 'default' チャンネル– SYM_ROUTER もノード間で一つだけ、

「元テーブルと同じテーブル名が宛先」のルータを定義● SYM_ROUTER には、どのノードグループからどのノードグ

ループであるか、と宛先スキーマ／テーブルを記述する

– 一つのテーブル間レプリケーションにつき、 SYM_TRIGGER と SYM_TRIGGER_ROUTER だけ記述

基本的な使い方 (4)

INSERT INTO sym_trigger (trigger_id, source_schema_name, source_table_name, channel_id, last_update_time, create_time)VALUES ('trg_foo', 'APP', 'FOO_TBL', 'default', current_timestamp, current_timestamp);

INSERT INTO sym_trigger_router (trigger_id, router_id, create_time, last_update_time)VALUES ('trg_foo', 'rt_ora2pg', current_timestamp, current_timestamp);

APP.FOO_TBL の同期を設定する２行

機能あれこれ (1)

両方向同期／カスケード同期● 両方向

– 単に両方向に同期を定義すれば良い

– 一貫性の保証は何も無し– 適用時にエラーになる

バッチは手動対応● カスケード

– 到着バッチからトリガ駆動する設定を与える

ノード１

ノード2

tbl1

tbl1

ノード3

tbl2

tbl2

tbl2

機能あれこれ (2)

マージ・パーティション同期● 値によって同期先を動的に決めることができる

支店2ノード

社員テーブル

伝票ID 支店ID 明細

102 2 .....

支店１ノード

社員テーブル

伝票ID 支店ID 明細101 1 .....

103 1 .....

本社ノード

社員テーブル

伝票ID 支店ID 明細101 1 .....

102 2 .....

103 1 .....支店ノードグループ

本社ノードグループ

機能あれこれ (3)

データ変形● 一部カラムを除外して同期● データを加工して同期

– 単純な処理（式計算、文字列を一定長切り捨てなど）– マップ定義に基づく置換– 別表を引いた結果で置換– bean shell

– Java Class による拡張

実際の利用時の課題 (1)

転送速度● やっぱりロジカルレプリケーションは遅い● 細かいトランザクションが大量発生すると各々が

バッチジョブになる → 転送オーバーヘッド増– 複数トランザクションを集約する設定が可能

● 発生源は 10,000 TPS → 宛先では 100TPS

● テーブルの初期ロードも遅い– いくつかのDBMSむけに bulk_loader 機能あり

● Oracle database、MySQL、PostgreSQL、MS SQL Server

実際の利用時の課題 (2)

マテビューDBLink との違い● 選択条件や値の加工、結合を伴うマテビューは、

簡単にはエミュレートできない– あくまでもテーブル単位の同期なので– 選択条件も条件カラム値が UPDATE されると面倒

● 結合の実現は難しい– 登場テーブルを同期して宛先側でマテビュー作る

● 選択条件や値の加工は bean shell 変形で対応

実際の利用時の課題 (3)

null pointer exception とか● 実装におけるエラー処理が雑

– OSS版 3.6系での話であって、3.7系や PRO版では改善されているかも

– ArrayIndexOutOfBoundsException や NullPointerException が出ても、まずは、設定の間違いを疑うべし（本来、ここそこが間違っています、と実装すべきだという意味ではバグだ）。

実際の利用時の課題 (4)

メモリ不足エラー● Javaサーバアプリなので、Javaサーブレットコン

テナのチューニングの技法が使える– JVMパラメータなど

● 「大きなバッチジョブ」が原因がポピュラー– 一つのジョブサイズを抑える設定– エラーになる大きいジョブサイズに合わせてメモリ設定– メモリ不足エラーは「一過性の状態が原因」と判断され

て繰り返される ～ ちょっと煩い

実際の利用時の課題 (5)

DBMSごとの違い● データの問題

– 単純にJDBC基準でデータ読み書きするだけ– VARCHAR(10) vs マルチバイト文字 など– timestampなど、型の小数点以下精度

● オブジェクト名の問題– デフォルトが大文字か小文字か？

● トリガプロシージャの違い– 「この条件設定はどの DB で動くか」を意識

UPDATE sym_trigger SET sync_on_insert_condition = ' :NEW.id > 100 ' ...

ご清聴ありがとうございました

Sourceforge のレビューが面白い。Lowest Ratedの感想も分からないでもない。