mysqlマルチソースレプリケーションの詳細
mysqlは他のデータベースよりも主従レプリケーションが最大の特色であることはご存じでしょうが、5.7以前のバージョンでは最大1主多従レプリケーション方式しかサポートされておらず、統計クラスのニーズに対しては、ライブラリをまたがる必要があります.これは面倒なことで、従来はデータベースミドルウェア(mycatなど)に任せるしかなく、バックアップ操作もありました.また、1つのライブラリでスクリプトを使用してポーリングまたは同時バックアップを行うだけで、時間と労力がかからないとは言えません.そして、マルチソースコピーの概念が出てきました.
マルチソースレプリケーションの概念はmariadbコミュニティが最初に提案したが、mysql公式が5.7のバージョンに積極的に導入した(5.6最新版もこの機能がない)、perconaは言わず、その後も発売された.この機能は上記の問題をよく解決し、最も直接的なのはもちろん手間が省け、同時複製もオンにすれば、イントラネット環境では、遅延はほとんど無視できる.
個人的には、マルチソース・レプリケーションは一意のスレーブ・ライブラリではなく、統計ライブラリまたはバックアップ・ライブラリを主な目的とする第2/3スレーブ・ライブラリまたは階層スレーブ・ライブラリを行うことをお勧めします.通常、マルチソース・レプリケーションは、データの競合を回避するために一部のデータベースとテーブルのレプリケーションを無視しますが、データベースの高可用性を向上させるためには、MHA環境とPXC環境がほぼ主従的に一致しているため、競合があり、高可用性を達成できないため、第2/3スレーブ・ライブラリまたは階層スレーブ・ライブラリを回避することができます.
環境の事前説明
現在テストされているアーキテクチャは、メインライブラリ1のwork 1とメインライブラリ2のwork 2であり、マルチソースからスレーブライブラリ3にコピーされ、システムライブラリmysqlライブラリを無視している.
メインライブラリ1:mysqlバージョン:アリクラウドrdsmysql 5.6.34,ipアドレス:10.2.0.5
メインライブラリ2:mysqlバージョン:percona-server 5を自己構築する.7.18,ipアドレス:10.2.0.6
ライブラリ3:mysqlバージョン:percona-server 5を自己構築する.7.18,ipアドレス:10.2.0.7
目的は次のとおりです.
メインライブラリ1---work 1
ライブラリ3から
メインライブラリ2---work 2/
どのようにmysqlデータベースを構築するかは私は言わないで、この点は各位が自分で研究して、私はこの文章を見たい人は構築の面で少なくとも圧力がないと推定して、同時に一定の業務のデータベースが存在すると仮定して、実はなくてもいいので、シミュレーションすればいいです.
そして、次の操作を見ます.
データベースのエクスポートとインポート
マルチソースレプリケーションでなくても、通常のプライマリ・レプリケーション環境ではデータのエクスポートとインポートが必要です.binlogは常に記録されているわけではありません(保存ポリシーの問題)、データ量が多ければ、彼を新しく走らせるのも現実的ではありません.
一方、マルチソースレプリケーションの本来の意味は、必要なデータベースのみをレプリケーションすることであるため、xtrabackupを使用すると適切ではありません.デフォルトではmysqlライブラリがバックアップされるので、この場合はmysqldumpを使用するのが適切です.前のライブラリがxtrabackupを使用しない限り、次はmysqldumpを使用します.mysqlpumpとmydumperも試してみることができると思います.
操作を見てみましょう
書き出しの可能性がある時にwarningsの警告があって、GTIDのsqlを設定することを書き出しますと言って、しかしこれはまさに私達の後で必要とするもので、だから無視することができます.
次に、目的のライブラリ環境にインポートしましょう.データが衝突しない限り、インポートできます.理論的には、マルチソース・レプリケーションは、同じ名前のデータベースの存在をすべて禁止しなければなりません.そうしないと、マルチソース・レプリケーションではありません.しかし、試してもいいと思います.個人的には試したことがありません.同じライブラリ名で、異なるデータテーブルをマルチソースでコピーしています.興味があれば、自分で試してみてください.ここでは展開しません.
ガイドが終わったら、厳密にデータテーブルがすべて入っているかどうかを見て、他は次のステップで構成を開始します.
マルチソースレプリケーション環境の構成
以下の操作は、ほとんどがライブラリから実行されています.プライマリ・ライブラリはせいぜいライセンスです.プライマリ・セカンダリ・アーキテクチャをすでに作成している場合は、一般的にこれもとっくにライセンスされているので、直接持ってきて使えばいいです.
主従レプリケーション環境が割り当てられている場合、古いモードはposの位置を決定し、新しいモードはGTIDを設定する番号であることがわかるはずです.どのように確定するかについては、moreを直接見てみればわかります.
ここでは詳しく解析するつもりはありませんが、興味のあるのは私のもう一つの一般的な主従アーキテクチャの構築に関する文章を見ることができます.中には詳細な解析があります.ここでgtidとposの値が見えますが、後で使えばいいです.
次に、本題に入ります.
まず、ライブラリプロファイルから変更して、何かを追加します.
特に注意が必要ですreplicate_wild_do_tableというパラメータは、あるライブラリまたはあるテーブルの同期文のみを実行することを意味し、他のライブラリとテーブルは処理されず、ビジネスライブラリを選択的にコピーする目的を達成し、無駄なデータも干渉もしません.公式ドキュメント解析では、1つのパラメータで1つのライブラリをマークすることしかできません.このパラメータはグローバルに共通しています.つまり、マルチソースレプリケーションでは、すべてのソースチャンネルでこの構成が共通しています.
読み取り専用read-onlyを開くのは言うまでもなく、マルチソースレプリケーションは一般的に読む必要があるので、ライブラリを書く可能性を持たせないでください.
マルチスレッドslave_の同時コピーparallel_workersは5.6,5.7の新しい機能で、レプリケーションの効率を効果的に速めることができます.特に5.7はトランザクションの同時レプリケーションをサポートしています.速度はかなり速く、ここではレプリケーション接続ごとに4つの同時スレッドが設定されています.
そしてslave_parallel_typeはコンカレントレプリケーション方式を選択し、デフォルトは5.6ライブラリモードでのコンカレントレプリケーションと互換性があるため、ここでは5.7に変更して新しくグループコミットトランザクションでコンカレントレプリケーションを行い、コンカレント効果はより良いが、主従サーバデータベースのバージョンが一致しない場合は、mysql 5のみであるため、変更しないほうがよい.7はデフォルトでグループコミット機能をオンにします.
--------------------------------------------------------------------
その後、マスターライブラリでコピーを許可したアカウントは、同類のアカウントの許可を受けたものは無視できます.
---------------------------------------------------------------------
さて、本格的にマルチソースコピーを配置し始めましたが、このGTIDモードは実は従来のposのモードよりも複雑ですが、未来はGTIDが多いので、GTIDモードでプレゼンテーションを主とします.
特に注意すべき点は、マルチソースレプリケーションはチャネルの識別を提供し、異なるソースチャネルを区別しているため、構成時に指定したチャネル名FOR CHANNEL'al_を付ける必要があることです.RDS';そうですか.GTIDの値とreplicate_wild_do_tableパラメータと同様に、デフォルトはグローバルな構成であり、ソースチャンネルをそれぞれ必要とするので、gtid値は、すべての*であるべきである.sqlファイルのgtid値の集合は、','で区切られ、最終的に私がこんなに多くのGTIDを設定する場合があります.
その後、すべての構成が完了すると、起動することができ、起動することも閉じることも特定のソースチャンネルを指定することができ、かなり便利です.以下にコマンドを挙げます.
そして、状態を見て、show slave statusを見てみましょう.
長い間、Replicate_Wild_Do_Table,Executed_Gtid_Setはグローバル汎用で、両方があり、私が言ったパラメータがグローバルであることを証明しました.そしてそれぞれのRetrieved_Gtid_Setは異なり、彼らは自分で選んだので、かなりスマートです.チャンネルを見てNameは彼らの異なるチャンネルの名前です.そして、Slave_IO_RunningとSlave_SQL_Runningのダブルyes,Master_Log_File=Relay_Master_Log_File,Read_Master_Log_Pos=Exec_Master_Log_Pos,Seconds_Behind_Masterは0なので、今は同期しています.
--------------------------------------------------------------------------
従来のパターンであれば、逆に簡単でGTIDの値を設定することなく、以下のようにlogファイル名とposを指定すればよい、SET@@GLOBALを設定する必要はない.GTID_PURGEDは起動できます.
--------------------------------------------------------------------------
問題の要約
1.マルチレプリケーション環境を停止するときは、パラレルレプリケーションの進行状況に注意してください.たとえば、次のような場合は、しばらく待ってから停止します.
それはあなたがこのように停止すると、並列コピーが途中で停止し、一部のデータがロールバックできないか、一部のデータのコピーエラーが発生する可能性があります.その後、彼を起こしたいと思ったら、間違いを報告する可能性が高いので、先に待ってから停止したほうがいいです.
もちろん、オンライン環境なら、いったいいつまで待てばいいのでしょうか.データベースが忙しくないときにやったほうがいいです.それとも、やり直す準備ができているのか、それでは来ましょう.
マルチソースレプリケーションの概念はmariadbコミュニティが最初に提案したが、mysql公式が5.7のバージョンに積極的に導入した(5.6最新版もこの機能がない)、perconaは言わず、その後も発売された.この機能は上記の問題をよく解決し、最も直接的なのはもちろん手間が省け、同時複製もオンにすれば、イントラネット環境では、遅延はほとんど無視できる.
個人的には、マルチソース・レプリケーションは一意のスレーブ・ライブラリではなく、統計ライブラリまたはバックアップ・ライブラリを主な目的とする第2/3スレーブ・ライブラリまたは階層スレーブ・ライブラリを行うことをお勧めします.通常、マルチソース・レプリケーションは、データの競合を回避するために一部のデータベースとテーブルのレプリケーションを無視しますが、データベースの高可用性を向上させるためには、MHA環境とPXC環境がほぼ主従的に一致しているため、競合があり、高可用性を達成できないため、第2/3スレーブ・ライブラリまたは階層スレーブ・ライブラリを回避することができます.
環境の事前説明
現在テストされているアーキテクチャは、メインライブラリ1のwork 1とメインライブラリ2のwork 2であり、マルチソースからスレーブライブラリ3にコピーされ、システムライブラリmysqlライブラリを無視している.
メインライブラリ1:mysqlバージョン:アリクラウドrdsmysql 5.6.34,ipアドレス:10.2.0.5
メインライブラリ2:mysqlバージョン:percona-server 5を自己構築する.7.18,ipアドレス:10.2.0.6
ライブラリ3:mysqlバージョン:percona-server 5を自己構築する.7.18,ipアドレス:10.2.0.7
目的は次のとおりです.
メインライブラリ1---work 1
ライブラリ3から
メインライブラリ2---work 2/
どのようにmysqlデータベースを構築するかは私は言わないで、この点は各位が自分で研究して、私はこの文章を見たい人は構築の面で少なくとも圧力がないと推定して、同時に一定の業務のデータベースが存在すると仮定して、実はなくてもいいので、シミュレーションすればいいです.
そして、次の操作を見ます.
データベースのエクスポートとインポート
マルチソースレプリケーションでなくても、通常のプライマリ・レプリケーション環境ではデータのエクスポートとインポートが必要です.binlogは常に記録されているわけではありません(保存ポリシーの問題)、データ量が多ければ、彼を新しく走らせるのも現実的ではありません.
一方、マルチソースレプリケーションの本来の意味は、必要なデータベースのみをレプリケーションすることであるため、xtrabackupを使用すると適切ではありません.デフォルトではmysqlライブラリがバックアップされるので、この場合はmysqldumpを使用するのが適切です.前のライブラリがxtrabackupを使用しない限り、次はmysqldumpを使用します.mysqlpumpとmydumperも試してみることができると思います.
操作を見てみましょう
#
mysqldump -uroot -p'******' -h10.2.0.5 -P3306 --triggers -R --single-transaction \
--no-autocommit --master-data=2 -q -e --databases work1 >work1.sql
mysqldump -uroot -p'******' -h10.2.0.6 -P3306 --triggers -R --single-transaction \
--no-autocommit --master-data=2 -q -e --databases work2 >work2.sql
書き出しの可能性がある時にwarningsの警告があって、GTIDのsqlを設定することを書き出しますと言って、しかしこれはまさに私達の後で必要とするもので、だから無視することができます.
次に、目的のライブラリ環境にインポートしましょう.データが衝突しない限り、インポートできます.理論的には、マルチソース・レプリケーションは、同じ名前のデータベースの存在をすべて禁止しなければなりません.そうしないと、マルチソース・レプリケーションではありません.しかし、試してもいいと思います.個人的には試したことがありません.同じライブラリ名で、異なるデータテーブルをマルチソースでコピーしています.興味があれば、自分で試してみてください.ここでは展開しません.
#
mysql -uroot -p'******' -h10.2.0.7 -P3306
>create database work1
>use work1
>source work1.sql
>create database work2
>use work2
>source work2.sql
#
mysql -uroot -p'******' -h10.2.0.7 -P3306 -e "create database work1;use work1;source work1.sql;"
mysql -uroot -p'******' -h10.2.0.7 -P3306 -e "create database work2;use work2;source work2.sql;"
ガイドが終わったら、厳密にデータテーブルがすべて入っているかどうかを見て、他は次のステップで構成を開始します.
マルチソースレプリケーション環境の構成
以下の操作は、ほとんどがライブラリから実行されています.プライマリ・ライブラリはせいぜいライセンスです.プライマリ・セカンダリ・アーキテクチャをすでに作成している場合は、一般的にこれもとっくにライセンスされているので、直接持ってきて使えばいいです.
主従レプリケーション環境が割り当てられている場合、古いモードはposの位置を決定し、新しいモードはGTIDを設定する番号であることがわかるはずです.どのように確定するかについては、moreを直接見てみればわかります.
# sql
more work1.sql
.
.
.
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758,
4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-38813008';
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.001284', MASTER_LOG_POS=3954096;
.
.
.
ここでは詳しく解析するつもりはありませんが、興味のあるのは私のもう一つの一般的な主従アーキテクチャの構築に関する文章を見ることができます.中には詳細な解析があります.ここでgtidとposの値が見えますが、後で使えばいいです.
次に、本題に入ります.
まず、ライブラリプロファイルから変更して、何かを追加します.
# my.cnf , mysql
vim my.cnf
[mysqld]
master_info_repository=TABLE
relay_log_info_repository=TABLE
replicate_wild_do_table=work1.%
replicate_wild_do_table=work2.%
read-only
#5.6 ,
slave_parallel_workers = 4
#5.7 , ,5.6
#slave_parallel_type = LOGICAL_CLOCK
# ,
mysql>SET GLOBAL master_info_repository = 'TABLE';
mysql>SET GLOBAL relay_log_info_repository = 'TABLE';
mysql>change replication filter REPLICATE_IGNORE_DB=(mysql) ;
特に注意が必要ですreplicate_wild_do_tableというパラメータは、あるライブラリまたはあるテーブルの同期文のみを実行することを意味し、他のライブラリとテーブルは処理されず、ビジネスライブラリを選択的にコピーする目的を達成し、無駄なデータも干渉もしません.公式ドキュメント解析では、1つのパラメータで1つのライブラリをマークすることしかできません.このパラメータはグローバルに共通しています.つまり、マルチソースレプリケーションでは、すべてのソースチャンネルでこの構成が共通しています.
読み取り専用read-onlyを開くのは言うまでもなく、マルチソースレプリケーションは一般的に読む必要があるので、ライブラリを書く可能性を持たせないでください.
マルチスレッドslave_の同時コピーparallel_workersは5.6,5.7の新しい機能で、レプリケーションの効率を効果的に速めることができます.特に5.7はトランザクションの同時レプリケーションをサポートしています.速度はかなり速く、ここではレプリケーション接続ごとに4つの同時スレッドが設定されています.
そしてslave_parallel_typeはコンカレントレプリケーション方式を選択し、デフォルトは5.6ライブラリモードでのコンカレントレプリケーションと互換性があるため、ここでは5.7に変更して新しくグループコミットトランザクションでコンカレントレプリケーションを行い、コンカレント効果はより良いが、主従サーバデータベースのバージョンが一致しない場合は、mysql 5のみであるため、変更しないほうがよい.7はデフォルトでグループコミット機能をオンにします.
--------------------------------------------------------------------
その後、マスターライブラリでコピーを許可したアカウントは、同類のアカウントの許可を受けたものは無視できます.
# ,
mysql -uroot -p'******' -h10.2.0.5 -P3306
grant replication slave on *.* to 'rep'@'%' identified by '123123';
mysql -uroot -p'******' -h10.2.0.6 -P3306
grant replication slave on *.* to 'rep'@'%' identified by '123123';
---------------------------------------------------------------------
さて、本格的にマルチソースコピーを配置し始めましたが、このGTIDモードは実は従来のposのモードよりも複雑ですが、未来はGTIDが多いので、GTIDモードでプレゼンテーションを主とします.
#
mysql -uroot -p'******' -h10.2.0.7 -P3306
#
reset slave all;
# , GTID
change master to
master_host='10.2.0.5',
master_user='rep',
master_password='123123',
master_port=3306,
MASTER_AUTO_POSITION = 1
FOR CHANNEL 'al_RDS';
# , GTID
change master to
master_host='10.2.0.6',
master_user='rep',
master_password='123123',
master_port=3306,
MASTER_AUTO_POSITION = 1
FOR CHANNEL 'me_mysql';
# GTID
reset master;
# GTID
SET @@GLOBAL.GTID_PURGED='09cb91bf-2669-11e7-8b70-00163e0835ff:1-486646,3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758,
4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-38813008';
特に注意すべき点は、マルチソースレプリケーションはチャネルの識別を提供し、異なるソースチャネルを区別しているため、構成時に指定したチャネル名FOR CHANNEL'al_を付ける必要があることです.RDS';そうですか.GTIDの値とreplicate_wild_do_tableパラメータと同様に、デフォルトはグローバルな構成であり、ソースチャンネルをそれぞれ必要とするので、gtid値は、すべての*であるべきである.sqlファイルのgtid値の集合は、','で区切られ、最終的に私がこんなに多くのGTIDを設定する場合があります.
その後、すべての構成が完了すると、起動することができ、起動することも閉じることも特定のソースチャンネルを指定することができ、かなり便利です.以下にコマンドを挙げます.
# /
start/stop slave;
# /
start/stop slave for channel 'al_RDS';
#
#RESET SLAVE FOR CHANNEL 'al_RDS';
# ,
#show slave status for channel 'al_RDS';
そして、状態を見て、show slave statusを見てみましょう.
#
mysql -uroot -p'******' -h10.2.0.7 -P3306
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.2.0.5
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.001297
Read_Master_Log_Pos: 5607291
Relay_Log_File: beifen1-relay-bin-al_rds.000030
Relay_Log_Pos: 5607464
Relay_Master_Log_File: mysql-bin.001297
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table: work1.%,work2.%
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 5607291
Relay_Log_Space: 5607767
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2721321239
Master_UUID: 4cdc2a74-6299-11e6-95ce-008cfaf595bc
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 4cdc2a74-6299-11e6-95ce-008cfaf595bc:38888940-39258544
Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-640645,
1db4cb1b-5e00-11e7-89eb-00163e046b4a:1-8,
3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758,
4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-39258544
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name: al_rds
Master_TLS_Version:
*************************** 2. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.2.0.6
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000013
Read_Master_Log_Pos: 246854093
Relay_Log_File: beifen1-relay-bin-me_mysql.000004
Relay_Log_Pos: 155502415
Relay_Master_Log_File: mysql-bin.000013
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table: work1.%,work2.%
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 246854093
Relay_Log_Space: 155502632
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 253241
Master_UUID: 817498dc-2676-11e7-a673-00163e024674
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:514003-640645
Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-640645,
1db4cb1b-5e00-11e7-89eb-00163e046b4a:1-8,
3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758,
4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-39258544
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name: me_mysql
Master_TLS_Version:
2 rows in set (0.00 sec)
長い間、Replicate_Wild_Do_Table,Executed_Gtid_Setはグローバル汎用で、両方があり、私が言ったパラメータがグローバルであることを証明しました.そしてそれぞれのRetrieved_Gtid_Setは異なり、彼らは自分で選んだので、かなりスマートです.チャンネルを見てNameは彼らの異なるチャンネルの名前です.そして、Slave_IO_RunningとSlave_SQL_Runningのダブルyes,Master_Log_File=Relay_Master_Log_File,Read_Master_Log_Pos=Exec_Master_Log_Pos,Seconds_Behind_Masterは0なので、今は同期しています.
--------------------------------------------------------------------------
従来のパターンであれば、逆に簡単でGTIDの値を設定することなく、以下のようにlogファイル名とposを指定すればよい、SET@@GLOBALを設定する必要はない.GTID_PURGEDは起動できます.
#
change master to
master_host='10.2.0.5',
master_user='rep',
master_password='123123',
master_port=3306,
MASTER_LOG_FILE='mysql-bin.001284',
MASTER_LOG_POS=3954096
FOR CHANNEL 'al_RDS';
#
change master to
master_host='10.2.0.6',
master_user='rep',
master_password='123123',
master_port=3306,
MASTER_LOG_FILE='mysql-bin.000014',
MASTER_LOG_POS=67456
FOR CHANNEL 'me_mysql';
#
start slave;
--------------------------------------------------------------------------
問題の要約
1.マルチレプリケーション環境を停止するときは、パラレルレプリケーションの進行状況に注意してください.たとえば、次のような場合は、しばらく待ってから停止します.
# Executed_Gtid_Set:
show slave status\G
.
.
.
Master_Server_Id: 2721321239
Master_UUID: 4cdc2a74-6299-11e6-95ce-008cfaf595bc
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Reading event from the relay log
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 4cdc2a74-6299-11e6-95ce-008cfaf595bc:50007036-50049107
Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-47551250,
3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758,
4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-50010063:50010080-50010093:50010099-50010101:50010108:50010130-50010139:50010145-50010148:50010158:50010179-50010184:50010190-50010200:50010207:50010215-50010221:50010227-50010236:50010243:50010276-50010285:50010291-50010293:50010300:50010308-50010312:50010326-50010328:50010371-50010373:50010391-50010393:50010403-50010405:50010427-50010429:50010464-50010466:50010480-50010482:50010490-50010496:50010518-50010520:50010538-50010540:50010551-50010553:50010574
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name: al_rds
Master_TLS_Version:
*************************** 2. row ***************************
Slave_IO_State: Waiting for master to send event
.
.
.
それはあなたがこのように停止すると、並列コピーが途中で停止し、一部のデータがロールバックできないか、一部のデータのコピーエラーが発生する可能性があります.その後、彼を起こしたいと思ったら、間違いを報告する可能性が高いので、先に待ってから停止したほうがいいです.
もちろん、オンライン環境なら、いったいいつまで待てばいいのでしょうか.データベースが忙しくないときにやったほうがいいです.それとも、やり直す準備ができているのか、それでは来ましょう.