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

PostgreSQL と MySQL 間のクロス レプリケーションと、XNUMX つのデータベース サーバー間のクロス レプリケーションを設定する方法について概説します。 通常、相互レプリケートされたデータベースは同種データベースと呼ばれ、ある RDBMS サーバーから別の RDBMS サーバーに移動する便利な方法です。

PostgreSQL データベースと MySQL データベースは一般にリレーショナルとみなされますが、追加の拡張機能を使用すると NoSQL 機能を提供します。 ここでは、リレーショナル DBMS の観点から PostgreSQL と MySQL の間のレプリケーションについて説明します。

ここでは内部の仕組み全体については説明しません。データベース サーバー間のレプリケーションの構成、利点、制限、使用例を理解できるように、基本原則だけを説明します。

通常、XNUMX つの同一のデータベース サーバー間のレプリケーションは、バイナリ モードで実行されるか、マスター (パブリッシャ、マスター、またはアクティブとも呼ばれます) とスレーブ (サブスクライバ、スタンバイ、またはパッシブ) の間のクエリを使用して実行されます。 レプリケーションの目的は、マスター データベースのリアルタイム コピーをスレーブ側に提供することです。 この場合、レプリケーションは一方向でのみ実行されるため、データはマスターからスレーブ、つまりアクティブからパッシブに転送されます。 ただし、XNUMX つのデータベース間のレプリケーションを両方向に設定して、データがアクティブ/アクティブ構成でスレーブからマスターに転送されるようにすることができます。 カスケード レプリケーションを含むこれらすべては、XNUMX つ以上の同一のデータベース サーバー間で可能です。アクティブ/アクティブまたはアクティブ/パッシブ構成は、ニーズ、初期構成でのそのような機能の可用性、または外部構成ソリューションの使用、および既存のトレードオフによって異なります。

説明した構成は、異なるデータベース サーバー間でも可能です。 サーバーは、別のデータベース サーバーから複製されたデータを受け入れ、複製されたデータのリアルタイム スナップショットを維持するように構成できます。 MySQL と PostgreSQL は、バイナリ ログ メソッド、ディスク ロック、ステートメントベースおよび行ベースのメソッドなど、これらの構成のほとんどを社内またはサードパーティの拡張機能を通じて提供します。

MySQL と PostgreSQL 間のクロス レプリケーションは、あるデータベース サーバーから別のデータベース サーバーへの XNUMX 回限りの移行に必要です。 これらのデータベースは異なるプロトコルを使用しているため、直接リンクすることはできません。 データ交換を確立するには、pg_chameleon などの外部オープン ソース ツールを使用できます。

pg_カメレオンとは

pg_chameleon は、Python 3 での MySQL から PostgreSQL へのレプリケーション システムです。これも Python のオープンソース mysql-replication ライブラリを使用します。 行イメージは MySQL テーブルから抽出され、JSONB オブジェクトとして PostgreSQL データベースに保存され、pl/pgsql 関数によって復号化されて PostgreSQL データベースに再現されます。

pg_chameleonの特徴

同じクラスターの複数の MySQL スキーマを、XNUMX 対多の構成で単一のターゲット PostgreSQL データベースにレプリケートできます
ソースとターゲットのスキーマ名を同じにすることはできません。
レプリケーション データは、カスケードされた MySQL レプリカから取得できます。
複製できないテーブルやエラーが発生するテーブルは除外されます。
各レプリケーション機能はデーモンによって制御されます。
YAML ベースのパラメーターと構成ファイルを介して制御します。

例

ホスト
vm1
vm2

OSバージョン
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

DBサーバーのバージョン
MySQLの5.7.26
PostgreSQL 10.5

DBポート
3306
5433

IPアドレス
192.168.56.102
192.168.56.106

まず、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 のインストールに使用されます。 以下のコマンドは、最新バージョンは 2.0.9 ですが、意図的に pg_chameleon 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 データベースです。 最後のセクションでは、ソース データ、つまりソース データベースの接続パラメータ、ソース データベースとターゲット データベース間のマッピング スキーム、スキップする必要があるテーブル、待機時間、メモリ、パッケージ サイズを示します。 「ソース」は複数形であることに注意してください。これは、複数のソース データベースを XNUMX つのターゲット データベースに追加して、多対 XNUMX 構成をセットアップできることを意味します。

サンプル データベース 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;

PostgreSQL 側では、MySQL データベースからの変更を受け入れる db_replica データベースが作成されます。 PostgreSQL のユーザー usr_replica は、実際のレプリケート テーブルとレプリケーション ディレクトリ テーブルをそれぞれ含む XNUMX つのスキーマ pgworld_x と sch_chameleon の所有者として自動的に構成されます。 以下に示すように、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

次の XNUMX つの pg_chameleon (カメレオン) コマンドは、環境を準備し、ソースを追加し、レプリカを初期化します。 すでに説明したように、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

これら XNUMX つのコマンドの出力は、それらが正常に実行されたことを明確に示しています。 クラッシュや構文エラーは、問題の解決方法のヒントを含むシンプルで明確なメッセージで報告されます。

最後に、start_replica を使用してレプリケーションを開始し、成功メッセージを受け取ります。

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

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

その結果

すでに述べたように、各レプリケーション機能はデーモンによって制御されます。 これらを表示するには、次に示すように、Linux ps コマンドを使用してプロセス テーブルをクエリします。

その結果

以下に示すように、レプリケーションはリアルタイムでテストするまで構成されているとは見なされません。 テーブルを作成し、いくつかのレコードを 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の利点

セットアップと構成が簡単。
明確なエラー メッセージで簡単にトラブルシューティングを行い、異常を特定します。
初期化後に残りの構成を変更せずに、追加の特別なテーブルをレプリケーションに追加できます。
単一のターゲット データベースに対して複数のソース データベースを構成することが可能であり、これは、XNUMX つ以上の MySQL データベースのデータを単一の PostgreSQL データベースに結合する場合に非常に便利です。
選択したテーブルを複製する必要はありません。

pg_chameleon の欠点

ソースとして MySQL 5.5 以降、ターゲット データベースとして PostgreSQL 9.5 以降でのみサポートされます。
各テーブルには主キーまたは一意キーが必要です。そうでない場合、テーブルは init_replica プロセス中に初期化されますが、レプリケートされません。
一方向レプリケーション - MySQL から PostgreSQL へのみ。 したがって、「アクティブ-パッシブ」回路にのみ適しています。
ソースとして使用できるのは MySQL データベースのみです。ソースとしての PostgreSQL データベースのサポートは実験的なものであり、制限があります (詳細はこちら) ここで)

pg_chameleon の結果

pg_chameleon のレプリケーション方法は、データベースを MySQL から PostgreSQL に移行するのに最適です。 重大な欠点は、レプリケーションが一方向のみであるため、データベースの専門家がレプリケーションを移行以外の目的で使用する可能性が低いことです。 しかし、一方向レプリケーションの問題は、別のオープンソース ツールである SymmetricDS を使用して解決できます。

詳細は公式ドキュメントをご覧ください ここで。 コマンドラインのヘルプが見つかります ここで.

SymmetricDSの概要

SymmetricDS は、任意のデータベースを他の一般的なデータベース (Oracle、MongoDB、PostgreSQL、MySQL、SQL Server、MariaDB、DB2、Sybase、Greenplum、Informix、H2、Firebird、およびその他のクラウド データベース インスタンス (例: Redshift)) にレプリケートするオープン ソース ツールです。 Azure など 利用可能な機能: データベースとファイルの同期、マルチマスター データベース レプリケーション、フィルター同期、変換など。 これは Java ツールであり、JRE または JDK の標準リリース (バージョン 8.0 以降) が必要です。 ここでは、ソース データベースのトリガーに対するデータ変更を記録し、バッチ形式で適切なターゲット データベースに送信できます。

SymmetricDS の機能

このツールはプラットフォームに依存しません。つまり、XNUMX つ以上の異なるデータベースがデータを交換できます。
リレーショナル データベースはデータ変更レコードを使用して同期されますが、ファイル システム ベースのデータベースはファイル同期を使用します。
一連のルールに基づいたプッシュおよびプル方式を使用した双方向レプリケーション。
データ転送は、安全で低帯域幅のネットワーク経由で可能です。
障害後にノードが動作を再開するときの自動回復と自動競合解決。
クラウド互換性のある強力な拡張 API。

例

SymmetricDS は、次の XNUMX つのオプションのいずれかで構成できます。
XNUMX つのスレーブ (子) ノード間のデータ複製を集中的に調整するマスター (親) ノード。子ノード間の通信は親を介してのみ行われます。
アクティブ ノード (ノード 1) は、仲介者なしで別のアクティブ ノード (ノード 2) と複製のために通信できます。

どちらのオプションでも、データ交換はプッシュとプルを使用して行われます。 この例では、アクティブ/アクティブ構成を検討します。 アーキテクチャ全体を説明すると長くなるので、調べてください。 руководствоSymmetricDS デバイスの詳細については、こちらをご覧ください。

SymmetricDS のインストールは非常に簡単です。zip ファイルのオープンソース バージョンをダウンロードします。 故に そして好きなところに取り出してください。 次の表は、この例の SymmetricDS のインストール場所とバージョン、および両方のノードのデータベース バージョン、Linux バージョン、IP アドレス、ポートに関する情報を示しています。

ホスト
vm1
vm2

OSバージョン
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

DBサーバーのバージョン
MySQLの5.7.26
PostgreSQL 10.5

DBポート
3306
5832

IPアドレス
192.168.1.107
192.168.1.112

SymmetricDSのバージョン
SymmetricDS 3.9
SymmetricDS 3.9

SymmetricDSのインストールパス
/usr/local/対称サーバー-3.9.20
/usr/local/対称サーバー-3.9.20

SymmetricDS ノード名
corp-000
ストア-001

ここでは、SymmetricDS を /usr/local/symmetric-server-3.9.20 にインストールします。そこにさまざまなサブディレクトリとファイルが保存されます。 私たちはサンプルとエンジンのサブディレクトリに興味があります。 サンプル ディレクトリには、ノード プロパティを含むサンプル構成ファイルと、すぐに開始できるサンプル SQL スクリプトが含まれています。

サンプル ディレクトリには、ノード プロパティを含む XNUMX つの構成ファイルがあります。名前は、特定のスキームにおけるノードの性質を示しています。

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

SymmetricDS には、基本的な 3 ノード設計 (オプション 1) に必要な構成ファイルがすべて含まれており、同じファイルを 2 ノード設計 (オプション 2) に使用できます。 必要な構成ファイルをサンプル ディレクトリから vm1 ホスト上のエンジンにコピーします。 次のようになります。

$> 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 と呼ばれ、データベース接続は、上記の接続文字列とログイン資格情報を使用する mysql jdbc ドライバーによって処理されます。 plica_db データベースに接続すると、スキーマの作成中にテーブルが作成されます。 sync.url は、同期のためにノードに接続する場所を示します。

ホスト vm2 上のノード 2 は store-001 として構成され、残りは以下の node.properties ファイルで指定されます。 ノードstore-001はPostgreSQLデータベースを実行し、pgdb_replicaはレプリケーションデータベースです。 register.url により、ホスト vm2 はホスト vm1 に接続し、ホスト vmXNUMX から構成の詳細を受信できるようになります。

$> 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 の例には、1 つのデータベース サーバー (000 つのノード) 間で双方向レプリケーションを設定するためのパラメータが含まれています。 以下の手順はホスト vm4 (corp-XNUMX) で実行され、XNUMX つのテーブルを持つサンプル スキーマが作成されます。 次に、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_delivery_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_ のプレフィックスが付く) は、create-sym-tables コマンドを実行し、レプリケーションを管理するノード corp-000 でのみ使用できることに注意してください。 また、ノード store-001 のデータベースには、データのないサンプル テーブルが 4 つだけあります。

全て。 以下に示すように、環境は両方のノードで sym サーバー プロセスを実行する準備ができています。

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

ログ エントリは、標準出力だけでなく、SymmetricDS がインストールされているディレクトリの logs フォルダにあるバックグラウンド ログ ファイル (symmetric.log) にも送信されます。 これで、ノードstore-001でsymサーバーを開始できるようになります。

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-001 からノード store-000 にブートストラップを送信できます。

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

この時点で、ノード corp-000 (ホスト: vm1) 上の MySQL データベースの項目テーブルに新しいレコードが挿入され、ノード 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 テーブルにレコードを挿入し、レプリケーションが成功したことを確認します。

その結果

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 の利点

XNUMX ノードまたは XNUMX ノード回路を作成するためのパラメータを含む既製のファイル セットを含む、インストールと構成が簡単です。
サーバー、ラップトップ、モバイル デバイスなど、クロスプラットフォームのデータベースとプラットフォームの独立性。
あらゆるデータベースをローカル、WAN、またはクラウド上の他のデータベースにレプリケートします。
便利なレプリケーションのために、いくつかのデータベースまたは数千のデータベースを使用して最適に動作する可能性があります。
GUIと優れたサポートを備えた有料版。

SymmetricDS の欠点

カタログ テーブルをロードするには、SQL ステートメントを使用してコマンド ラインでレプリケーションのルールと方向を手動で定義する必要がありますが、これは不便な場合があります。
スクリプトを使用してレプリケーションのルールと方向を定義する SQL ステートメントを作成しない限り、レプリケーション用に多数のテーブルを設定するのは面倒な作業になる可能性があります。
ログに記録される情報が多すぎるため、スペースを占有しすぎないようにログ ファイルを整理する必要がある場合があります。

SymmetricDS の結果

SymmetricDS を使用すると、XNUMX つ、XNUMX つ、あるいは数千のノード間で双方向レプリケーションを設定して、ファイルを複製および同期できます。 これは、ノードでの長期間のダウンタイム後の自動データ回復、HTTPS を介したノード間の安全かつ効率的なデータ交換、一連のルールに基づく自動競合管理など、多くのタスクを独立して実行する独自のツールです。 SymmetricDS は、したがって、任意のデータベース間でレプリケーションを実行できるため、プラットフォーム間でのデータの移行、移行、分散、フィルタリング、変換など、さまざまなシナリオに使用できます。

例は公式に基づいています クイックガイド SymmetricDS による。 で ユーザーマニュアル SymmetricDS を使用したレプリケーションのセットアップに関連するさまざまな概念について詳しく説明します。

出所： habr.com