PostgreSQLとMySQLのクロスレプリケーションの概要

このブログは、PostgreSQLとMySQL間のクロスレプリケーションの概要を説明し、2つのデータベースサーバー間のクロスレプリケーションを構成する方法についてさらに説明することを目的としています。従来、クロスレプリケーションのセットアップに関係するデータベースは異種データベースと呼ばれ、あるRDBMSサーバーから別のサーバーに移動するための優れたアプローチです。

PostgreSQLデータベースとMySQLデータベースはどちらも従来のRDBMSデータベースですが、両方の長所を活かすための拡張機能が追加されたNoSQL機能も提供します。この記事では、RDBMSの観点からPostgreSQLとMySQL間のレプリケーションについて説明します。

レプリケーションの内部に関する徹底的な説明はこのブログの範囲内ではありませんが、データベースサーバー間でレプリケーションがどのように構成されているか、利点、制限、およびおそらくいくつかの既知のユースケースを聴衆に理解させるために、いくつかの基本的な要素について説明する必要があります。

一般に、2つの同一のデータベースサーバー間のレプリケーションは、マスターノード（パブリッシャー、プライマリ、またはアクティブと呼ばれる）とスレーブノード（サブスクライバー、スタンバイ、またはパッシブ）の間でバイナリモードまたはクエリモードのいずれかで実行されます。レプリケーションの目的は、スレーブ側でマスターデータベースのリアルタイムコピーを提供することです。ここで、データはマスターからスレーブに転送されます。これにより、レプリケーションは一方向でのみ発生するように構成されているため、アクティブ-パッシブセットアップが形成されます。一方、2つのデータベース間のレプリケーションは双方向で構成できるため、データをスレーブからマスターに転送して、アクティブ-アクティブ構成を確立することもできます。これらはすべて、カスケードレプリケーションを含む可能性のある2つ以上の同一のデータベースサーバー間で構成できます。アクティブ-アクティブまたはアクティブ-パッシブの構成は、実際にはビジネスニーズ、ネイティブ構成内でのそのような機能の可用性、または構成するための外部ソリューションの利用と適用可能なトレードオフに依存します。

上記の構成は、さまざまなデータベースサーバーで実現できます。データベースサーバーは、別の完全に異なるデータベースサーバーから複製されたデータを受け入れ、複製されるデータのリアルタイムスナップショットを維持するように構成できます。 MySQLとPostgreSQLの両方のデータベースサーバーは、上記の構成のほとんどを、独自の方法で、またはバイナリログ方式、ディスクブロック方式、ステートメントベース、行ベースの方式などのサードパーティの拡張機能を使用して提供します。

MySQLとPostgreSQLの間のクロスレプリケーションを構成する要件は、あるデータベースサーバーから別のデータベースサーバーに移動するための1回限りの移行作業の結果として実際に発生します。両方のデータベースが異なるプロトコルを使用しているため、相互に直接通信することはできません。そのコミュニケーションフローを実現するために、pg_chameleonなどの外部オープンソースツールがあります。

pg_chameleonの背景

pg_chameleonは、Python 3で開発されたMySQLからPostgreSQLへのレプリケーションシステムです。これも、Pythonを使用して開発されたmysql-replicationと呼ばれるオープンソースライブラリを使用します。この機能には、MySQLテーブルの行イメージをプルしてJSONBオブジェクトとしてPostgreSQLデータベースに保存することが含まれます。これは、pl / pgsql関数によってさらにデコードされ、PostgreSQLデータベースに対してそれらの変更を再生します。

pg_chameleonの機能

• 同じクラスターからの複数のMySQLスキーマを単一のターゲットPostgreSQLデータベースに複製して、多対1の複製セットアップを形成できます
• ソーススキーマ名とターゲットスキーマ名は同一でない場合があります
• レプリケーションデータはMySQLカスケードレプリカから取得できます
• 複製またはエラーの生成に失敗したテーブルは除外されます
• 各レプリケーション機能は、デーモンを使用して管理されます
• YAMLコンストラクトに基づくパラメーターと構成ファイルを使用して制御

デモ

まず、pg_chameleonをインストールするために必要なすべての前提条件を使用してセットアップを準備します。このデモでは、Python 3.6.8がインストールされ、仮想環境が作成され、使用できるようにアクティブ化されます。

$> wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tar.xz
$> tar -xJf Python-3.6.8.tar.xz
$> cd Python-3.6.8
$> ./configure --enable-optimizations
$> make altinstall

Python3.6のインストールが成功すると、仮想環境の作成やアクティブ化など、さらに追加の要件が満たされます。そのpipモジュールに加えて、最新バージョンにアップグレードされ、pg_chameleonのインストールに使用されます。以下のコマンドでは、pg_chameleon 2.0.9が意図的にインストールされていますが、最新バージョンは2.0.10です。これは、更新されたバージョンで新たに導入されたバグを回避するために行われます。

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

次のステップは、set_configuration_files引数を指定してpg_chameleon（chameleonはコマンド）を呼び出し、pg_chameleonがデフォルトのディレクトリと構成ファイルを作成できるようにすることです。

(venv) $> chameleon set_configuration_files
creating directory /root/.pg_chameleon
creating directory /root/.pg_chameleon/configuration/
creating directory /root/.pg_chameleon/logs/
creating directory /root/.pg_chameleon/pid/
copying configuration  example in /root/.pg_chameleon/configuration//config-example.yml

次に、config-example.ymlのコピーをdefault.ymlとして作成し、デフォルトの構成ファイルにします。このデモで使用した構成ファイルのサンプルを以下に示します。

$> cat default.yml
---
#global settings
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: file
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''

# type_override allows the user to override the default type conversion into a different one.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  destination connection
pg_conn:
  host: "192.168.56.106"
  port: "5433"
  user: "usr_replica"
  password: "pass123"
  database: "db_replica"
  charset: "utf8"

sources:
  mysql:
    db_conn:
      host: "192.168.56.102"
      port: "3306"
      user: "usr_replica"
      password: "pass123"
      charset: 'utf8'
      connect_timeout: 10
    schema_mappings:
      world_x: pgworld_x
    limit_tables:
#      - delphis_mediterranea.foo
    skip_tables:
#      - delphis_mediterranea.bar
    grant_select_to:
      - usr_readonly
    lock_timeout: "120s"
    my_server_id: 100
    replica_batch_size: 10000
    replay_max_rows: 10000
    batch_retention: '1 day'
    copy_max_memory: "300M"
    copy_mode: 'file'
    out_dir: /tmp
    sleep_loop: 1
    on_error_replay: continue
    on_error_read: continue
    auto_maintenance: "disabled"
    gtid_enable: No
    type: mysql
    skip_events:
      insert:
        - delphis_mediterranea.foo #skips inserts on the table delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #skips deletes on schema delphis_mediterranea
      update:

このデモで使用されている構成ファイルは、ソース環境と宛先環境に合わせて若干の編集が加えられたpg_chameleonに付属するサンプルファイルであり、構成ファイルのさまざまなセクションの概要が続きます。

default.yml構成ファイルには、ロックファイルの場所、ログの場所、保持期間などの詳細を制御する「グローバル設定」セクションがあります。次のセクションは、オーバーライドする一連のルールである「タイプオーバーライド」セクションです。レプリケーション中のタイプ。 tinyint（1）をブール値に変換するサンプルタイプオーバーライドルールがデフォルトで使用されます。次のセクションは、宛先データベース接続の詳細セクションです。この場合は、「pg_conn」で示されるPostgreSQLデータベースです。最後のセクションは、ソースデータベース接続設定、ソースと宛先間のスキーママッピング、タイムアウト、メモリ、バッチサイズ設定などのスキップするテーブルのすべての詳細を含むソースセクションです。多対1のレプリケーション設定を形成するために、単一の宛先に複数のソースが存在する可能性があることを示す「ソース」に注意してください。

このデモでは「world_x」データベースが使用されています。これは、MySQLコミュニティがデモ目的で提供するサンプル行を含む4つのテーブルを持つサンプルデータベースであり、ここからダウンロードできます。サンプルデータベースは、tarおよび圧縮アーカイブとして、データベースを作成して行をインポートするための手順とともに提供されます。

MySQLデータベースとPostgreSQLデータベースの両方にusr_replicaと同じ名前の専用ユーザーが作成され、複製されるすべてのテーブルへの読み取りアクセス権を持つために、MySQLに対する追加の権限がさらに付与されます。

mysql> CREATE USER usr_replica ;
mysql> SET PASSWORD FOR usr_replica='pass123';
mysql> GRANT ALL ON world_x.* TO 'usr_replica';
mysql> GRANT RELOAD ON *.* to 'usr_replica';
mysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica';
mysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica';
mysql> FLUSH PRIVILEGES;

「db_replica」という名前のMySQLデータベースからの変更を受け入れるデータベースがPostgreSQL側に作成されます。 PostgreSQLの「usr_replica」ユーザーは、「pgworld_x」や「sch_chameleon」など、実際に複製されたテーブルと複製のカタログテーブルをそれぞれ含む2つのスキーマの所有者として自動的に構成されます。この自動構成は、以下に示すcreate_replica_schema引数によって行われます。

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

以下に示すように、MySQLデータベースは、レプリケーションの準備をするためにいくつかのパラメーター変更を使用して構成されており、変更を有効にするにはデータベースサーバーを再起動する必要があります。

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

この時点で、両方のデータベースサーバーへの接続をテストして、pg_chameleonコマンドの実行時に問題がないことを確認することが重要です。

PostgreSQLノードの場合：

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x 

MySQLノードの場合：

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

pg_chameleon（chameleon）の次の3つのコマンドは、環境をセットアップし、ソースを追加し、レプリカを初期化する場所です。 pg_chameleonの「create_replica_schema」引数は、すでに説明したように、PostgreSQLデータベースにデフォルトスキーマ（sch_chameleon）とレプリケーションスキーマ（pgworld_x）を作成します。 「add_source」引数は、構成ファイル（default.yml）（この場合は「mysql」）を読み取ることによってソースデータベースを構成に追加し、「init_replica」は構成ファイルの設定に基づいて構成を初期化します。

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

上記の3つのコマンドの出力は自明であり、各コマンドの成功を明確な出力メッセージで示します。失敗や構文エラーは、単純でわかりやすいメッセージで明確に示されているため、修正アクションが提案および促されます。

最後のステップは、「start_replica」でレプリケーションを開始することです。その成功は、以下に示すような出力ヒントによって示されます。

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

レプリケーションのステータスは「show_status」引数で照会でき、エラーは「show_errors」引数で表示できます。

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

前に説明したように、各レプリケーション機能はデーモンを使用して管理されます。デーモンは、Linuxの「ps」コマンドを使用してプロセステーブルをクエリすることで表示できます。

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

以下のようにシミュレートされた「リアルタイム適用」テストにかけられるまで、レプリケーションのセットアップは完了しません。これには、テーブルの作成とMySQLデータベースへのいくつかのレコードの挿入が含まれ、その後、pg_chameleonの「sync_tables」引数が呼び出されてデーモンが更新され、テーブルとそのレコードがPostgreSQLデータベースに複製されます。

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values (1,'one');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (2,'two');
Query OK, 1 row affected (0.00 sec)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Sync tables process for source mysql started.

テストは、PostgreSQLデータベースからテーブルをクエリして行を反映することで確認されます。

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

移行プロジェクトの場合、次のpg_chameleonコマンドは移行作業の終了を示します。すべてのターゲットテーブルの行がレプリケートされたことを確認した後でコマンドを実行する必要があります。その結果、ソースデータベースまたはレプリケーションスキーマ（sch_chameleon）への参照なしでクリーンに移行されたPostgreSQLデータベースになります。

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

オプションで、次のコマンドはソース構成とレプリケーションスキーマを削除します。

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

pg_chameleonの使用の長所

• セットアップが簡単で、構成もそれほど複雑ではありません
• エラー出力を理解しやすい、痛みのないトラブルシューティングと異常検出
• 他の構成を変更せずに、初期化後に追加のアドホックテーブルをレプリケーションに追加できます
• 単一の宛先データベースに対して複数のソースを構成できます。これは、1つ以上のMySQLデータベースからのデータを単一のPostgreSQLデータベースにマージする統合プロジェクトで役立ちます。
• 選択したテーブルは複製をスキップできます

pg_chameleonを使用することの短所

• OriginデータベースとしてMySQL5.5以降、および宛先データベースとしてPostgreSQL9.5以降でのみサポートされます
• すべてのテーブルに主キーまたは一意キーが必要です。そうでない場合、テーブルはinit_replicaプロセス中に初期化されますが、複製に失敗します
• 一方向のレプリケーション、つまりMySQLからPostgreSQLへ。これにより、その使用をアクティブ-パッシブセットアップのみに制限します
• ソースデータベースはMySQLデータベースのみにすることができますが、ソースとしてのPostgreSQLデータベースのサポートは実験的なものであり、さらに制限があります（詳細についてはここをクリックしてください）

pg_chameleonの概要

pg_chameleonが提供するレプリケーションアプローチは、MySQLからPostgreSQLへのデータベース移行に適しています。ただし、一方向レプリケーションの重要な制限の1つは、データベースの専門家が移行以外の目的でそれを採用することを思いとどまらせる可能性があります。単方向レプリケーションのこの欠点は、SymmetricDSと呼ばれるさらに別のオープンソースツールを使用して対処できます。

ユーティリティをより詳細に研究するには、こちらの公式ドキュメントを参照してください。コマンドラインリファレンスはここから取得できます。

SymmetricDSの概要

SymmetricDSは、Oracle、MongoDB、PostgreSQL、MySQL、SQL Server、MariaDB、DB2、Sybase、Greenplum、Informix、H2などの一般的なデータベースサーバーのリストから、任意のデータベースを他のデータベースに複製できるオープンソースツールです。 Firebird、およびRedshiftやAzureなどの他のクラウドベースのデータベースインスタンス。一部の製品には、データベースとファイルの同期、マルチマスターレプリケーション、フィルター処理された同期、および変換が含まれます。このツールはJavaを使用して開発されており、JREまたはJDKの標準エディション（バージョン8.0以降）が必要です。この機能には、ソースデータベースのトリガーによってキャプチャされ、送信バッチとして参加している宛先データベースにルーティングされるデータ変更が含まれます

SymmetricDSの機能

• プラットフォームに依存しない。つまり、2つ以上の異なるデータベースが相互に通信でき、任意のデータベースから他のデータベースと通信できます。
• リレーショナルデータベースは変更データキャプチャを使用して同期を実現し、ファイルシステムベースのシステムはファイル同期を利用します
• 設定されたルールに基づいて実行されるプッシュアンドプル方式を使用した双方向レプリケーション
• データ転送は、安全で低帯域幅のネットワークでも発生する可能性があります
• クラッシュしたノードの再開中の自動回復と自動競合解決
• クラウド対応で、強力な拡張APIが含まれています

デモ

SymmetricDSは、次の2つのオプションのいずれかで構成できます。

• 2つのスレーブ（子）ノード間のデータレプリケーションを調整する一元化された仲介者として機能するマスター（親）ノード。2つの子ノード間の通信は親を介してのみ行うことができます。
• アクティブノード（node1）は、仲介なしで別のアクティブノード（node2）との間で複製できます。

どちらのオプションでも、ノード間の通信は「プッシュ」イベントと「プル」イベントを介して行われます。このデモでは、2つのノード間のアクティブ-アクティブ構成について説明します。完全なアーキテクチャは網羅的である可能性があるため、SymmetricDSの内部について詳しくは、こちらのユーザーガイドを確認することをお勧めします。

SymmetricDSのインストールは、ここからオープンソースバージョンのzipファイルをダウンロードして、便利な場所に解凍するだけです。このデモのインストール場所とSymmetricDSのバージョンの詳細は、データベースバージョン、Linuxバージョン、IPアドレス、および参加している両方のノードの通信ポートに関するその他の詳細とともに、以下の表のとおりです。

この場合のインストールホームは「/usr/local/symmetric-server-3.9.20」です。これは、他のさまざまなサブディレクトリとファイルを含むSymmetricDSのホームディレクトリになります。現在重要なサブディレクトリの2つは、「サンプル」と「エンジン」です。サンプルディレクトリには、クイックデモを開始するためのサンプルSQLスクリプトに加えて、ノードプロパティ構成ファイルのサンプルが含まれています。

次の3つのノードプロパティ構成ファイルは、「samples」ディレクトリにあり、特定のセットアップでのノードの性質を示す名前が付いています。

corp-000.properties
store-001.properties
store-002.properties

SymmetricDSには、基本的な3ノードセットアップ（オプション1）をサポートするために必要なすべての構成ファイルが付属しているため、同じ構成ファイルを使用して2ノードセットアップ（オプション2）もセットアップすると便利です。目的の構成ファイルは、「samples」ディレクトリからホストvm1の「engines」にコピーされ、次のようになります。

$> cat engines/corp-000.properties
engine.name=corp-000
db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://192.168.1.107:3306/replica_db?autoReconnect=true&useSSL=false
db.user=root
db.password=admin123
registration.url=
sync.url=http://192.168.1.107:31415/sync/corp-000
group.id=corp
external.id=000

SymmetricDS構成でのこのノードの名前は「corp-000」であり、データベース接続は、ログイン資格情報とともに上記の接続文字列を使用してmysqljdbcドライバーで処理されます。接続するデータベースは「replica_db」であり、サンプルスキーマの作成中にテーブルが作成されます。 「sync.url」は、同期のためにノードに接続する場所を示します。

ホストvm2のノード2は「store-001」として構成され、残りの詳細は以下に示すnode.propertiesファイルで構成されています。 「store-001」ノードは、レプリケーション用のデータベースとして「pgdb_replica」を使用してPostgreSQLデータベースを実行します。 「registration.url」を使用すると、ホスト「vm2」がホスト「vm1」と通信して構成の詳細を取得できます。

$> cat engines/store-001.properties
engine.name=store-001
db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://192.168.1.112:5832/pgdb_replica
db.user=postgres
db.password=admin123
registration.url=http://192.168.1.107:31415/sync/corp-000
group.id=store
external.id=001

SymmetricDSの事前構成されたデフォルトのデモには、2つのデータベースサーバー（2つのノード）間で双方向レプリケーションをセットアップするための設定が含まれています。以下の手順は、ホストvm1（corp-000）で実行され、4つのテーブルを持つサンプルスキーマが作成されます。さらに、「symadmin」コマンドを使用して「create-sym-tables」を実行すると、ノード間のレプリケーションのルールと方向を格納および制御するカタログテーブルが作成されます。最後に、デモテーブルにサンプルデータが読み込まれます。

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> ./dbimport --engine corp-000 --format XML create_sample.xml
vm1$> ./symadmin --engine corp-000 create-sym-tables
vm1$> ./dbimport --engine corp-000 insert_sample.sql

デモテーブル「item」と「item_selling_price」は、corp-000からstore-001に複製されるように自動構成され、saleテーブル（sale_transactionとsale_return_line_item）は、store-001からcorp-000に複製されるように自動構成されます。次のステップは、ホストvm2（store-001）のPostgreSQLデータベースにサンプルスキーマを作成して、corp-000からデータを受信できるようにすることです。

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

この段階で、vm1上のMySQLデータベースにデモテーブルとSymmetricDSカタログテーブルが存在することを確認することが重要です。 SymmetricDSシステムテーブル（プレフィックス「sym_」が付いたテーブル）は、現時点ではcorp-000ノードでのみ使用できます。これは、「create-sym-tables」コマンドが実行された場所であるためです。レプリケーションを制御および管理します。それに加えて、store-001ノードデータベースには、データが含まれていない4つのデモテーブルしかありません。

これで、以下に示すように、環境は両方のノードで「sym」サーバープロセスを開始する準備が整いました。

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

ログエントリは、SymmetricDSインストール場所のlogsディレクトリの下にあるバックグラウンドログファイル（symmetric.log）と、標準出力の両方に送信されます。これで、「sym」サーバーをstore-001ノードで開始できるようになりました。

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &

ホストvm2で「sym」サーバープロセスを起動すると、PostgreSQLデータベースにもSymmetricDSカタログテーブルが作成されます。両方のノードで「sym」サーバープロセスを起動すると、ノードが相互に調整され、corp-000からstore-001にデータが複製されます。数秒後、いずれかの側の4つのテーブルすべてにクエリを実行すると、正常なレプリケーション結果が表示されます。または、以下のコマンドを使用して、corp-000からstore-001ノードに初期ロードを送信することもできます。

vm1$> ./symadmin --engine corp-000 reload-node 001

この時点で、新しいレコードがcorp-000ノード（ホスト：vm1）のMySQLデータベースの「item」テーブルに挿入され、store-001ノード（ホスト：vm2）のPostgreSQLデータベースに正常に複製されたことを確認できます。 ）。これは、corp-000からstore-001へのデータの「プル」イベントを示しています。

mysql> insert into item values ('22000002','Jelly Bean');
Query OK, 1 row affected (0.00 sec)

vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item" 
 item_id  |   name
----------+-----------
 11000001 | Yummy Gum
 22000002 | Jelly Bean
(2 rows)

store-001からcorp-000へのデータの「プッシュ」イベントは、レコードを「sale_transaction」テーブルに挿入し、それが複製されることを確認することで実現できます。

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

これは、MySQLデータベースとPostgreSQLデータベース間のデモテーブルの双方向レプリケーションの構成が成功したことを示しています。一方、新しく作成されたユーザーテーブルのレプリケーションの構成は、次の手順を使用して実行できます。デモ用にサンプルテーブル「t1」が作成され、そのレプリケーションのルールは以下の手順に従って構成されます。この手順では、corp-000からstore-001へのレプリケーションのみを構成します。

mysql> create table  t1 (no integer);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into sym_channel (channel_id,create_time,last_update_time) 
values ('t1',current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id,
last_update_time, create_time) values ('t1', 't1', 't1', current_timestamp,
current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger_router (trigger_id, router_id,
Initial_load_order, create_time,last_update_time) values ('t1',
'corp-2-store-1', 1, current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

この後、テーブル定義に一致するトリガーを再作成する「sync-triggers」引数を指定してsymadminコマンドを呼び出すことにより、新しいテーブルを追加するスキーマの変更について構成に通知されます。続いて、「send-schema」を実行してスキーマの変更をstore-001ノードに送信します。その後、「t1」テーブルのレプリケーションが正常に構成されます。

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

SymmetricDSを使用するメリット

• 3ノードまたは2ノードのセットアップを構築するための事前構成されたパラメータファイルのセットを含む簡単なインストールと構成
• クロスプラットフォームデータベースが有効で、サーバー、ラップトップ、モバイルデバイスを含むプラットフォームに依存しません
• オンプレミス、WAN、クラウドを問わず、任意のデータベースを他のデータベースに複製します
• 数千のデータベースから数千のデータベースを最適に処理して、データをシームレスに複製することができます
• ソフトウェアの商用バージョンは、優れたサポートパッケージを備えたGUI駆動の管理コンソールを提供します

SymmetricDSを使用することの短所

• 手動のコマンドライン構成では、SQLステートメントを使用して複製のルールと方向を定義し、カタログテーブルをロードする必要がある場合があります。これは、管理が不便な場合があります。
• レプリケーション用に多数のテーブルを設定することは、レプリケーションのルールと方向を定義するSQLステートメントを生成するために何らかの形式のスクリプトを使用しない限り、徹底的な作業になります。
• ログファイルを乱雑にする大量のログ情報。これにより、ログファイルがディスクをいっぱいにしないように、定期的なログファイルのメンテナンスが必要になります。

SymmetricDSの概要

SymmetricDSは、2ノード、3ノードなどの間で双方向レプリケーションをセットアップして、数千ノードがデータをレプリケートし、ファイルの同期を実現する機能を提供します。これは、ノードでの長期間のダウンタイム後のデータの自動回復、HTTPSを使用したノード間の安全で効率的な通信、設定されたルールに基づく自動競合管理など、多くの自己修復メンテナンスタスクを実行する独自のツールです。 , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.