MySQL データベースのグループ レプリケーションには、IP アドレスを踏むという落とし穴が存在します

はじめに

MySQL バージョン 5.7.17 のレプリケーション機能には、新機能である輝く星機能グループ レプリケーションが導入されました。当然、構築やテストにはある程度の経験が不可欠ですが、構築の過程でホスト名に関する落とし穴に遭遇しました。以下では、その構築方法と、この落とし穴に遭遇するプロセスについて説明します。

2

予想

仮想マシン 192.168.56.102 上に 2 つのインスタンス 3306 と 3307 を構築し、192.168.56.105 上に 1 つのインスタンス 3308 を構築します。特性に応じて、グループ レプリケーションを開始するノードとしてノードを選択する必要があります。この記事では、起動ノードとして 3306 を選択します。

3

2. group_name の形式は UUID であり、MySQL で select uuid(); を実行して取得できます。

レプリケーションアカウントの作成:

[mysqld3306]
gtid-mode=on
enforce-gtid-consistency=on
 
master-info-repository=table
relay-log-info-repository=table
 
binlog-checksum=none
log-slave-updates=on
binlog-format=row
 
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="2dc52aec-cfea-11e6-95f3-080027264cfa"
loose-group_replication_start_on_boot=off # 开机启动OFF
loose-group_replication_local_address="192.168.56.102:33061"
loose-group_replication_group_seeds="192.168.56.102:33061,192.168.56.102:33071,192.168.56.105:33081"
loose-group_replication_bootstrap_group=off # 作为首个启动OFF

レプリケーションチャネルの作成:

mysql> set sql_log_bin=0;
mysql> create user 'group_repl'@'%' identified by 'group_repl';
mysql> grant replication slave on *.* to 'group_repl'@'%';
mysql> flush privileges;
mysql> set sql_log_bin=1;

プラグインのロード:

mysql> change master to master_user='group_repl',master_password='group_repl' for channel 'group_replication_recovery';

最初のノードとしてグループレプリケーションを開始:

mysql> install plugin group_replication soname 'group_replication.so';

インスタンス192。 168.56.1 02:3307 および 192.168 56.105:3308

残りのインスタンスのほとんどの操作は 102:3306 と同じです。異なる部分のみを以下に示します。コピーを作成する場合 アカウントを設定し、チャネルをコピーし、プラグインをロードした後、102:3307 と 105:3308 の両方で start group_replication; を実行するだけで済みます。

4

確認

グループ レプリケーションに参加するかどうかを確認するには、テーブル Performance_schema.replication_group_members をクエリするだけです。以下は、102:3307 がグループに参加している状況です:

mysql> set @@global.group_replication_bootstrap_group=1;
mysql> start group_replication;
mysql> set @@global.group_replication_bootstrap_group=0;
mysql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: 4f987d01-cff0-11e6-9afa-080027264cfa
 MEMBER_HOST: localhost
 MEMBER_PORT: 3306
MEMBER_STATE: ONLINE

すでに 2 つのノード、つまり 102:3306 と 102:3307 がグループを形成していることがわかります。

5

問題

105:3308 に参加し始めたときに、問題が発生しました。 3308 がグループに参加できないことがわかります:

loose-group_replication_local_address="192.168.56.102:33071"，105:3308的参数：loose-group_replication_local_address="192.168.56.105:33081"；

エラー ログを見ると、次のことがわかります:

mysql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: 4f987d01-cff0-11e6-9afa-080027264cfa
 MEMBER_HOST: localhost
 MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: d8f7405d-cff1-11e6-b449-080027264cfa
 MEMBER_HOST: localhost
 MEMBER_PORT: 3307
MEMBER_STATE: ONLINE

問題は MEMBER_HOST にあると推測されるので、ホスト名を IP アドレスに変更します。テストの結果、

mysql> select * from performance_schema.replication_group_members;
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: 4f987d01-cff0-11e6-9afa-080027264cfa
 MEMBER_HOST: localhost
 MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: 645aef9a-d000-11e6-a756-080027d54077
 MEMBER_HOST: localhost
 MEMBER_PORT: 3308
MEMBER_STATE: RECOVERING
*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: d8f7405d-cff1-11e6-b449-080027264cfa
 MEMBER_HOST: localhost
 MEMBER_PORT: 3307
MEMBER_STATE: ONLINE

が実現可能であることが判明しました。しかし、実際の状況では、ホスト名を IP に設定することは不可能です。そこで、何度も試みた結果、次の方法でこの問題を解決できることがわかりました。

1. 異なる物理マシン (仮想マシン) に異なるホスト名を設定します。

2. 各物理マシンを作成するために /etc/hosts を変更します。 (仮想マシン) ) はホスト名を通じて ping できます。

上記の作業が完了したら、最後にグループのメンバーを確認します:

...
2017-01-02T17:35:02.123501Z 32 [Note] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. 
Previous state master_host=&#39;<NULL>&#39;, master_port= 0, master_log_file=&#39;&#39;, master_log_pos= 4, master_bind=&#39;&#39;. 
New state master_host=&#39;localhost&#39;, master_port= 3306, master_log_file=&#39;&#39;, master_log_pos= 4, master_bind=&#39;&#39;.
...
2017-01-02T17:35:02.133661Z 34 [ERROR] Slave I/O for channel &#39;group_replication_recovery&#39;: error connecting to master &#39;group_repl@localhost:3306&#39; - retry-time: 60
  retries: 1, Error_code: 2003
...

問題は解決されました。もう 1 つ注意すべき点は、物理マシン (仮想マシン) 下のインスタンスであっても、グループを形成するにはホスト名と IP の間のマッピング関係が必要であることです。上記のローカルホストの状況で同じ物理マシンの下にグループを形成できる理由は、システムがデフォルトで 127.0.0.1 からローカルホストへのマッピング関係を持っているためです。

6

概要

上記の問題は、MySQL がレプリケーションを構成するときに一般的に使用される IP アドレスではなく、オペレーティング システムのホスト名を直接使用するために発生します。これはバグであるはずで、私より数日前に誰かがそこにいたのです。 . バグレポートを公式に提出してください。グループ レプリケーションを構成するとき、バグが修正される前に、ホスト名と IP アドレス間のマッピング関係が設定されているかどうかを確認することをお勧めします。

上記は、IP アドレス ピットを構築するための MySQL データベース グループ レプリケーションの内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。