MySQL 8.0.23 のレプリケーション アーキテクチャにおけるスレーブ ノードの自動フェイルオーバー

私はしばらく MGR と連絡を取り合ってきました。MySQL 8.0.23 の登場により、MySQL グループ レプリカ (MGR) に基づく高可用性アーキテクチャが新しいアーキテクチャのアイデアを提供します。

災害復旧室のスレーブがメインコンピュータ室の MGR をより適切にサポートするにはどうすればよいでしょうか?

MGR が故障できるノードの数はいくつですか?

今回は、上記2つの質問をもとに、MGRの考え方や機能について簡単にお話ししたいと思います。

1. MySQLグループレプリケーションメンバー数のフォールトトレランス

上の表は皆さんもよくご存知だと思います。私はよくインタビューで「4 ノードの MGR ノードのうち、最大で何ノードが故障する可能性がありますか?」と尋ねます。ほとんどの人は「最大で 1 ノードが故障する可能性があります。2 ノードが故障すると、脳が分裂し、システムが機能しなくなります」と答えます。

それでは、MGR がどのように処理するかを見てみましょう。これが答えでしょうか?

1) 4ノードMGRがあります

質問です: この図は明らかにシングル モードですが、矢印は一方向ではありません。間違って描かれているのでしょうか?

2) このとき、Second-04 が突然クラッシュし、MGR クラスターはどうなるのでしょうか?

クラスターのステータスは次のようになります。

• 各ノードは一定の時間に独自の情報を交換します。
• Second-04ノードから情報が受信されない場合、他のメンバーは5秒間待機します。
• この期間中、Second-04 は確かにメッセージを送信しなかったため、健全なメンバーは Second-04 が疑わしい状態にあると判断し、UNREACHABLE としてマークしました。
• その後、正常なメンバーは、パラメータ group_replication_member_expel_timeout に従って待機を続けます (この時点で Second-04 はまだ UNREACHABLE ステータスです)。
• group_replication_member_expel_timeout 時間を超過すると、正常なメンバーは Second-04 ノードをクラスターから排除します。

ここでポイントです。黒板に注目してください

Second-04で、追放されていない場合:

この時点で、クラスターは (4 ノード - 3 正常 - 1 不良) です。この期間中に 1 つのノードに障害が発生すると、クラスターは (4 ノード - 2 正常 - 2 不良) になります。クラスターは多数決原理を満たさず、各ノードに書き込むことはできません (手動介入を行ってクラスター メンバー リストを強制的に指定しない限り)。

Second-04では、射出された後：

この時点で、クラスターは (3 ノード - 3 正常 - 0 不良) です。4 ノード クラスターは、3 ノードの正常なクラスターに縮退します。この時点で、クラスターは引き続きノード障害を起こし、(3 ノード - 2 正常 - 1 不良) になる可能性があります。

したがって、4 ノード クラスター内の 1 つのノードまたは 2 つのノードに障害が発生するかどうかは、クラスター処理の段階によって異なります。

追伸:

先ほど述べた問題について話しましょう。この図は明らかにシングルモードですが、矢印は一方向ではありません。間違って描かれているのでしょうか?

まず、シングル モードでは、デフォルトでは 2 番目のノードに書き込むことはできませんが、これは 2 番目のノードのスーパー読み取り専用設定が有効になっているためです。

2 番目のノードのスーパー読み取り専用を 0 に設定します。2 番目のノードは通常どおり書き込み可能で、他のノード (プライマリ ノードと他の 2 番目のノード) と同期できます。送信は引き続き Paxos プロトコルに基づいています。

トレインを実行する: 2 番目のノードは、競合検出フェーズを経由せずに他のノードを逆方向に同期します (理論上の効率はマルチ書き込みモードよりも高くなります)。検証されていないため、興味がある場合は研究することができます。

2. 非同期接続フェイルオーバー

MySQL 8.0.22 では、非同期レプリケーション接続フェイルオーバーが導入されました。多くの友人がこれを紹介する記事を公開しています。ここでは簡単に説明します。

1) 同じコンピュータルームにマスターノードとスレーブノードを 1 つずつ配置し、リモートコンピュータルームにスレーブノードを配置する

2) マスターが故障し、スレーブ01がマスターになり、スレーブ02は元のマスターに接続できなくなります。

3) Slave-02 に「非同期接続フェイルオーバー構成」が設定されている場合、Slave-02 は元のマスターの障害を認識した後、事前定義された構成に従って元の Slave-01 (新しいマスター) とのレプリケーション関係を自動的に確立しようとします。

この機能は非常に優れています。参照されているサードパーティ ツール (MHA のマスター スレーブ関係の修復など) は、MySQL ネイティブ関数に置き換えることができます。

しかし、テストを終えた後、いくつか疑問が湧きました。

1. 「非同期」レプリケーションフェイルオーバーは半同期アーキテクチャをサポートしませんか?データが失われないことを保証できず、MHA を完全に置き換えることもできないのですか?
回答: 実際には、拡張された準同期をサポートしています。

2. フェールオーバーのマスター リストを事前に構成する必要がある場合、コンピュータ ルーム A のアーキテクチャが変更された場合でも、コンピュータ ルーム B のノードを保守する必要がありますか?
A: はい。

3. コンピュータルームAがMGRの場合、MGRのノード（マスター）が異常であるが、サービスはシャットダウンされておらずアクセスできる場合、コンピュータルームBのノードは常に接続されているべきではないですか？
答え: はい

その後、MySQL 8.0.23 がリリースされ、次の機能強化がもたらされました。

スレーブは MGR クラスターをサポートし、MGR メンバーを動的に識別してマスターとスレーブの関係を確立できます。

最後に、1周走ってみましょう。

1) まず、3 ノードの MGR クラスター、バージョン 8.0.22 があります (非同期接続フェイルオーバーはスレーブの IO スレッドで機能するため、スレーブのバージョンは 8.0.23 です)

+----------------------------+-------------+--------------+-------------+---------------------+
| 現在(6) | メンバーホスト | メンバー状態 | メンバーロール | VIEW_ID |
+----------------------------+-------------+--------------+-------------+---------------------+
| 2021-01-22 13:41:27.902251 | mysql-01 | オンライン | セカンダリ | 16112906030396799:9 |
| 2021-01-22 13:41:27.902251 | mysql-02 | オンライン | プライマリ | 16112906030396799:9 |
| 2021-01-22 13:41:27.902251 | mysql-03 | オンライン | セカンダリ | 16112906030396799:9 |
+----------------------------+-------------+--------------+-------------+---------------------+

2) 次に、独立したスレーブノードで「マスター接続のフェイルオーバーリスト」を指定します。

SELECT 非同期接続フェイルオーバー追加管理('ch1'、'GroupReplication'、'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1'、'mysql-02'、3306、''、80、60);

パラメータを簡単に説明します。
ch1: チャネル名 GroupReplication: ハードコードされたパラメータ。現在、MGR クラスタをサポートしています aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1: MGR グループ名 (パラメータ group_replication_group_name)
mysql-02: MGR メンバーの 1 つ 80: プライマリ ノードの優先度 (0 ～ 100)。同じ優先度のマスターが複数ある場合は、マスターとして機能するノードがランダムに選択されます。
60: 基本的にシングルモード用に用意された第2ノードの優先度（0～100）

3) スレーブのレプリケーションチャネル情報を指定する

チャネル 'ch1' の場合、レプリケーション ソースを SOURCE_USER='rpl_user'、SOURCE_PASSWORD='123456'、SOURCE_HOST='mysql-02'、SOURCE_PORT=3306、SOURCE_RETRY_COUNT=2、SOURCE_CONNECTION_AUTO_FAILOVER=1、SOURCE_AUTO_POSITION=1 に変更します。

4) スレーブを起動し、「接続転送可能リスト」を確認します。

io スレッドが有効になっていない場合、MGR メンバーは自動的に認識されません。そしてユーザーをコピーする

rpl_user は、MGR ノードの performance_schema に対する選択権限を持っている必要があります。

スレーブを起動します。
performance_schema.replication_asynchronous_connection_failover から * を選択します。
+--------------+----------+------+-------------------+--------+--------------------------------------+
| チャンネル名 | ホスト | ポート | ネットワーク名前空間 | 重み | 管理対象名 |
+--------------+----------+------+-------------------+--------+--------------------------------------+
| ch1 | mysql-01 | 3306 | | 60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1 |
| ch1 | mysql-02 | 3306 | | 80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1 |
| ch1 | mysql-03 | 3306 | | 60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1 |
+--------------+----------+------+-------------------+--------+--------------------------------------+

5) 次に、mysql-02 の group_replication を停止します (サービスをシャットダウンしません)。

スレーブ リストは自動的に mysql-02 を削除し、他のノード (mysql-02 (プライマリ)) に再接続します。

グループレプリケーションを停止します。

-- 奴隷:
performance_schema.replication_asynchronous_connection_failover から * を選択します。
+--------------+----------+------+-------------------+--------+--------------------------------------+
| チャンネル名 | ホスト | ポート | ネットワーク名前空間 | 重み | 管理対象名 |
+--------------+----------+------+-------------------+--------+--------------------------------------+
| ch1 | mysql-01 | 3306 | | 80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1 |
| ch1 | mysql-03 | 3306 | | 60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1 |
+--------------+----------+------+-------------------+--------+--------------------------------------+

スレーブステータスを表示\G
************************** 1. 行 ****************************
        Slave_IO_State: マスターがイベントを送信するのを待機中
         マスターホスト: mysql-01
         マスターユーザー: rpl_user
         マスターポート: 3306
        接続再試行: 60
       マスターログファイル: mybinlog.000003
     読み取りマスターログ位置: 4904
        リレーログファイル:mysql-01-relay-bin-ch1.000065
        リレーログ位置: 439
    リレーマスターログファイル: mybinlog.000003
       スレーブIO実行中: はい
      スレーブSQL実行中: はい
      ...

これで設定は完了です。後で MGR ノードが追加または削除されると、スレーブはこのリストを自動的に維持できます。その他のユースケースは投稿されません。

追伸:

スレーブによって確立されたマスターノード (プライマリ) の接続を別のノード (セカンダリ) に手動で切り替える場合は、「レプリケーション接続の転送可能なリスト」を削除し、セカンダリの優先順位を再調整して追加し直すだけです。

-- 構成を削除します SELECTsynchronous_connection_failover_delete_managed('ch1', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1');


-- Second の優先度を Primary より高く再追加して調整します
SELECT 非同期接続フェイルオーバー追加管理('ch1'、'GroupReplication'、'aaaaaaaaaaaaa-aaaa-aaaa-aaaaaaaaaa1'、'mysql-03'、3306、''、60、80);

参考リンク:

https://mysqlhighavailability.com/automatic-asynchronous-replication-connection-failover/

https://my.oschina.net/u/4591256/blog/4813037

レプリケーション関数のソースリスト

これで、MySQL 8.0.23 のレプリケーション アーキテクチャ スレーブ ノードの自動フェイルオーバーに関するこの記事は終了です。MySQL の自動フェイルオーバーの詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。