Mysql 5.7マルチソースレプリケーションおよびパラレルレプリケーション機能
環境の準備:
os version:CentOS release 6.5 (Final)
サーバ情報:
Master1:192.168.1.29
Master2:192.168.1.37
Slave:192.168.1.86
1,修正my.cnf
Slaveのmy.cnfは以下のパラメータを加える
enhanced multi-threaded slave(マルチスレッドレプリケーション)の有効化
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8
パラレル・レプリケーションの監視は、次のとおりです.
mysql> show tables like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+----------------------------------
2,権限,master 1およびmaster 2での権限,slaveレプリケーションの許可
3,change master
change master tomaster_host="192.168.1.29",master_port=3306,master_user="root",master_password="Password@123456"FOR CHANNEL "master1";
change master tomaster_host="192.168.1.37",master_port=3306,master_user="root",master_password="Password@123456"FOR CHANNEL "master2";
4,slaveを起動する
MySQL 5.7は、本格的なパラレルレプリケーションと呼ぶことができます.その最も主要な原因は、slaveサーバの再生がホストと一致していることです.つまり、masterサーバ上でどのようにパラレルに実行されているslave上でどのようにパラレル再生を行うかです.ライブラリの並列レプリケーションの制限はなくなり、バイナリ・ログ・フォーマットにも特別な要件はありません(ライブラリ・ベースの並列レプリケーションも必要ありません).
MySQLの公式から見ると、その並列レプリケーションの本来の計画は表レベルの並列レプリケーションと行レベルの並列レプリケーションをサポートすることであり、行レベルの並列レプリケーションはROW形式のバイナリログを解析することによって完成し、WL＃4648.しかし、最終的にパートナーに現れたのは、開発計画の中でMTS:Prepared transactions slave parallel applierと呼ばれています.WL#6314がわかります.この並列レプリケーションの考え方は、MariaDBのKristainが最初に提案し、MariaDB 10に登場しており、多くのMariaDBを選択するパートナーが最も重視している機能の一つが並列レプリケーションであると信じている.
os version:CentOS release 6.5 (Final)
サーバ情報:
Master1:192.168.1.29
Master2:192.168.1.37
Slave:192.168.1.86
1,修正my.cnf
Slaveのmy.cnfは以下のパラメータを加える
enhanced multi-threaded slave(マルチスレッドレプリケーション)の有効化
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8
master_info_repository= TABL relay_log_info_repository= TABLE relay_log_recovery= ON パラレル・レプリケーションの監視は、次のとおりです.
mysql> show tables like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+----------------------------------
2,権限,master 1およびmaster 2での権限,slaveレプリケーションの許可
3,change master
change master tomaster_host="192.168.1.29",master_port=3306,master_user="root",master_password="Password@123456"FOR CHANNEL "master1";
change master tomaster_host="192.168.1.37",master_port=3306,master_user="root",master_password="Password@123456"FOR CHANNEL "master2";
4,slaveを起動する
start slave for channel "master1"; start slave for channel "master2"; MySQL 5.7は、本格的なパラレルレプリケーションと呼ぶことができます.その最も主要な原因は、slaveサーバの再生がホストと一致していることです.つまり、masterサーバ上でどのようにパラレルに実行されているslave上でどのようにパラレル再生を行うかです.ライブラリの並列レプリケーションの制限はなくなり、バイナリ・ログ・フォーマットにも特別な要件はありません(ライブラリ・ベースの並列レプリケーションも必要ありません).
MySQLの公式から見ると、その並列レプリケーションの本来の計画は表レベルの並列レプリケーションと行レベルの並列レプリケーションをサポートすることであり、行レベルの並列レプリケーションはROW形式のバイナリログを解析することによって完成し、WL＃4648.しかし、最終的にパートナーに現れたのは、開発計画の中でMTS:Prepared transactions slave parallel applierと呼ばれています.WL#6314がわかります.この並列レプリケーションの考え方は、MariaDBのKristainが最初に提案し、MariaDB 10に登場しており、多くのMariaDBを選択するパートナーが最も重視している機能の一つが並列レプリケーションであると信じている.