MySQL8.0.22での非同期レプリケーションの自動フェイルオーバー

Oracleは最近MySQL8.0.22をリリースしました。この新しいバージョンには、新しい非同期接続フェイルオーバーメカニズムが付属しています。これにより、レプリカは、既存のソースに障害が発生した場合に、新しいソースへの非同期レプリケーション接続を自動的に確立できます。

このブログでは、この接続フェイルオーバーメカニズムについて説明します。

概要

非同期フェイルオーバーメカニズムを使用して、データを共有するサーバーのグループ（マルチソーススレーブ）とレプリカの同期を維持できます。既存のソース接続に障害が発生すると、レプリケーション接続が新しいソースに移動します。

動作原理

既存の接続ソースに障害が発生すると、レプリカは最初に、MASTER_RETRY_COUNTで指定された回数だけ同じ接続を再試行します。試行の間隔は、MASTER_CONNECT_RETRYオプションによって設定されます。これらの試行がなくなると、非同期接続フェイルオーバーメカニズムがフェイルオーバープロセスを引き継ぎます。

デフォルトでは、MASTER_RETRY_COUNTは86400（1日-> 24時間）であり、MASTER_CONNECT_RETRYのデフォルト値は60であることに注意してください。

非同期接続フェイルオーバーメカニズムを迅速にアクティブ化できるようにするには、一時的なネットワークが原因で接続障害が発生した場合に備えて、MASTER_RETRY_COUNTを、同じソースで数回再試行できる最小数に設定します。停止。

非同期接続フェイルオーバーをアクティブ化する方法

レプリケーションチャネルの非同期接続フェイルオーバーをアクティブにするには、チャネルのCHANGEMASTERTOステートメントでSOURCE_CONNECTION_AUTO_FAILOVER=1を設定します。
2つの新しい関数があり、ソースリストからサーバーエントリを追加および削除するのに役立ちます。
- asynchronous_connection_failover_add_source（ソースリストからサーバーエントリを追加）
- asynchronous_connection_failover_delete_source（ソースリストからサーバーエントリを削除します）

これらの関数を使用するときは、（'channel'、'host'、port、'network_namespace'、weight）のような引数を指定する必要があります。

例

mysql> select asynchronous_connection_failover_add_source('testing', '192.168.33.12', 3306, '', 100);

+----------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('testing', '192.168.33.12', 3306, '', 100) |

+----------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.           |

+----------------------------------------------------------------------------------------+

1 row in set (0.00 sec)

ソースサーバーはテーブル「mysql.replication_asynchronous_connection_failover」で構成する必要があります。テーブル「performance_schema.replication_asynchronous_connection_failover」を使用して、ソースリストで使用可能なサーバーを表示することもできます。

注：チャネルベースのレプリケーションを使用していない場合、このフェイルオーバーメカニズムは機能します。 change masterステートメントの実行中は、チャネル名を指定する必要はありません。ただし、すべてのサーバーでGTIDが有効になっていることを確認してください。

本番環境のユースケース

ProxySQLの背後で実行されている本番データを含む3つのPXC-5.7ノードがあるとします。次に、ノード1（192.168.33.12）でチャネルベースの非同期レプリケーションを構成します。

ノード1-192.168.33.12 ノード2-192.168.33.13 ノード3-192.168.33.14 レプリカの読み取り-192.168.33.15

mysql> change master to master_user='repl',master_password='[email protected]',master_host='192.168.33.12',master_auto_position=1,source_connection_auto_failover=1,master_retry_count=3,master_connect_retry=6 for channel "prod_replica";

Query OK, 0 rows affected, 2 warnings (0.01 sec)



mysql> start replica for channel 'prod_replica';

Query OK, 0 rows affected (0.00 sec)

アーキテクチャ図

テストケース1 フェイルオーバー設定を追加します：

 mysql> select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100);

+---------------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100) |

+---------------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.            |

+---------------------------------------------------------------------------------------------+

1 row in set (0.00 sec)



mysql>  select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80);

+--------------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80) |

+--------------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.               |

+--------------------------------------------------------------------------------------------+

1 row in set (0.01 sec)



mysql>  select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60);

+--------------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60) |

+--------------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.            |

+--------------------------------------------------------------------------------------------+

1 row in set (0.00 sec)




mysql> select * from mysql.replication_asynchronous_connection_failover;

+-------------------+---------------+------+-------------------+--------+

| Channel_name | Host         | Port | Network_namespace | Weight |

+-------------------+---------------+------+-------------------+--------+

| prod_replica      | 192.168.33.12 | 3306 |                   |    100 |

| prod_replica      | 192.168.33.13 | 3306 |                   |     80 |

| prod_replica      | 192.168.33.14 | 3306 |                   |     60 |

+-------------------+---------------+------+-------------------+--------+

3 rows in set (0.00 sec)

わかりました、auto_failoverをアクティブにできます。ノード1（192.168.33.12）MySQLを停止しましょう。 ProxySQLは、次の適切なマスターをプロモートします。

[[email protected] lib]# service mysqld stop

Redirecting to /bin/systemctl stop mysqld.service

レプリカサーバー内

mysql> show replica status\G

*************************** 1. row ***************************

               Slave_IO_State: Reconnecting after a failed master event read

                  Master_Host: 192.168.33.12

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 6

              Master_Log_File: binlog.000004

          Read_Master_Log_Pos: 1143

               Relay_Log_File: relay-bin-testing.000006

                Relay_Log_Pos: 1352

        Relay_Master_Log_File: binlog.000004

             Slave_IO_Running: Connecting

            Slave_SQL_Running: Yes

              Replicate_Do_DB: 

Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 10 retries: 2 message: Can't connect to MySQL server on '192.168.33.12' (111)

IOスレッドは「接続中」の状態です。これは、master_retry_countとmaster_connect_retryの設定に基づいて、既存のソース（ノード1）から接続を確立しようとしていることを意味します。

数秒後、source_hostがノード2（192.168.33.13）に変更されたことがわかります。これでフェイルオーバーが完了しました。

mysql> show replica status\G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.33.13

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 6

              Master_Log_File: binlog.000004

          Read_Master_Log_Pos: 1162

               Relay_Log_File: relay-bin-testing.000007

                Relay_Log_Pos: 487

        Relay_Master_Log_File: binlog.000004

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

             Last_IO_Error:

エラーログから

2020-10-29T22:22:05.679951Z 54 [ERROR] [MY-010584] [Repl] Slave I/O for channel 'prod_replica': error reconnecting to master '[email protected]:3306' - retry-time: 10 retries: 3 message: Can't connect to MySQL server on '192.168.33.12' (111), Error_code: MY-002003

2020-10-29T22:22:05.681121Z 58 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.

2020-10-29T22:22:05.682830Z 58 [System] [MY-010562] [Repl] Slave I/O thread for channel 'prod_replica': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 2660

2020-10-29T22:22:05.685175Z 58 [Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was 31b5b7d0-1a25-11eb-8076-080027090068.

(END)

テストケース2

変更マスターステートメントの実行中、チャネルベースのレプリケーションを使用しているかどうかに関係なく、チャネル名を指定する必要はありません。

例

mysql> change master to master_user='repl',master_password='[email protected]',master_host='192.168.33.12',master_auto_position=1,source_connection_auto_failover=1,master_retry_count=3,master_connect_retry=10;

Query OK, 0 rows affected, 2 warnings (0.01 sec)



mysql> start replica;

Query OK, 0 rows affected (0.00 sec)

次に、以下のようなフェイルオーバー設定を追加します

select asynchronous_connection_failover_add_source('', '192.168.33.12', 3306, '', 100);

select asynchronous_connection_failover_add_source('', '192.168.33.13', 3306, '', 80);

select asynchronous_connection_failover_add_source('', '192.168.33.14', 3306, '', 60);



 mysql> select * from mysql.replication_asynchronous_connection_failover;

+--------------+---------------+------+-------------------+--------+

| Channel_name | Host          | Port | Network_namespace | Weight |

+--------------+---------------+------+-------------------+--------+

|              | 192.168.33.12 | 3306 |                   |    100 |

|              | 192.168.33.13 | 3306 |                   |     80 |

|              | 192.168.33.14 | 3306 |                   |     60 |

+--------------+---------------+------+-------------------+--------+

3 rows in set (0.00 sec)

次に、ノード1（192.168.33.12）を停止します。

レプリケーションエラー

Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 10 retries: 2 message: Can't connect to MySQL server on '192.168.33.12' (111)

エラーログから

2020-10-30T00:38:03.471482Z 27 [ERROR] [MY-010584] [Repl] Slave I/O for channel '': error connecting to master '[email protected]:3306' - retry-time: 10 retries: 3 message: Can't connect to MySQL server on '192.168.33.12' (111), Error_code: MY-002003

2020-10-30T00:38:03.472002Z 29 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.

2020-10-30T00:38:03.473493Z 29 [System] [MY-010562] [Repl] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 234

2020-10-30T00:38:03.475471Z 29 [Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was 1ff8a919-1a39-11eb-a27a-080027090068.

ClusterControlの使用

次に、ClusterControlを使用してこの自動フェイルオーバープロセスを繰り返します。 ClusterControlによってデプロイされた3つのノードpxc（5.7）があります。 PXC node2の下に8.0.22レプリケーションスレーブがあり、ClusterControlを使用してこのリードレプリカを追加します。

ステップ1

ClusterControlノードからのパスワードなしのSSHログインをセットアップしてレプリカノードを読み取ります。

$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15

ステップ2

ClusterControlに移動し、ドロップダウンアイコンをクリックして、[レプリケーションスレーブの追加]オプションを選択します。

ステップ3

次に、[既存のレプリケーションスレーブ]オプションを選択し、リードレプリカIPを入力して、[レプリケーションスレーブの追加]をクリックします。

ステップ4

ジョブがトリガーされ、ClusterControl>ログ>ジョブで進行状況を監視できます。プロセスが完了すると、次のスクリーンショットで強調表示されているように、スレーブが概要ページに表示されます。

これで、ClusterControl>トポロジ

で現在のトポロジを確認できます。

レプリカの自動フェイルオーバープロセス

次に、フェイルオーバーテストを実行し、リードレプリカのこの関数（asynchronous_connection_failover_add_source）に以下の設定を追加します。

 select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100);

 select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80);

 select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60);



mysql> select * from mysql.replication_asynchronous_connection_failover;

+--------------+---------------+------+-------------------+--------+

| Channel_name | Host          | Port | Network_namespace | Weight |

+--------------+---------------+------+-------------------+--------+

| prod_replica | 192.168.33.12 | 3306 |                   |    100 |

| prod_replica | 192.168.33.13 | 3306 |                   |     80 |

| prod_replica | 192.168.33.14 | 3306 |                   |     60 |

+--------------+---------------+------+-------------------+--------+

3 rows in set (0.00 sec)



mysql> select CONNECTION_RETRY_INTERVAL,CONNECTION_RETRY_COUNT,SOURCE_CONNECTION_AUTO_FAILOVER from performance_schema.replication_connection_conf

iguration;

+---------------------------+------------------------+---------------------------------+

| CONNECTION_RETRY_INTERVAL | CONNECTION_RETRY_COUNT | SOURCE_CONNECTION_AUTO_FAILOVER |

+---------------------------+------------------------+---------------------------------+

|                         6 |                      3 | 1                               |

+---------------------------+------------------------+---------------------------------+

1 row in set (0.00 sec)

ノード2（192.168.33.13）を停止します。 ClusterControlでは、（enable_cluster_autorecovery）パラメーターが有効になっているため、次の適切なマスターが昇格します。

現在のマスターがダウンしているため、リードレプリカが接続を再試行していますマスター。

リードレプリカからのレプリケーションエラー

Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 6 retries: 2 message: Can't connect to MySQL server on '192.168.33.13' (111)

ClusterControlが次の適切なマスターをプロモートすると、読み取りレプリカは使用可能なクラスターノードのいずれかに接続します。

自動フェイルオーバープロセスが完了し、リードレプリカがノード1に参加しました（192.168.33.13）サーバー。

結論

これはMySQLの優れた機能の1つであり、手動による介入は必要ありません。この自動フェイルオーバープロセスにより、時間を節約できます。また、レプリカサーバーの停止を減らします。注目に値するのは、古いマスターがローテーションに戻ったときに、レプリケーション接続が古いマスターに戻らないことです。