このセクションでは、グループレプリケーションの設定をアップグレードする方法について説明します。グループメンバーをアップグレードする基本的な手順は、単一のインスタンスをアップグレードする手順と同じです。アップグレード方法については、特にin-situアップグレード（mysql_upgradeコマンドを使用して元のデータファイルに基づいてデータディクショナリをアップグレードする）または論理アップグレード（事前に新しいバージョンのサーバーを構築する）を選択できます。グループに保存されているデータの量に応じて、古いバージョンのデータが論理的にエクスポートされてから、新しいバージョンにインポートされます。一般に、インプレースアップグレードの方が高速であるため、インプレースアップグレードを使用してアップグレードすることをお勧めします。
グループのオンラインアップグレード中に、グループの可用性を最大化するために（グループの可用性を確保するために可能な限り）、グループのメンバーに対してローリングアップグレード（1つずつ更新）を実行する必要があります。したがって、グループ内で異なるMySQLを同時に実行する必要がある場合があります。サーバーバージョンのメンバー。グループに異なるバージョンのメンバーが含まれている場合、いくつかの互換性戦略があります。これにより、アップグレードプロセス中に同じグループで異なるバージョンのMySQLを実行しているメンバーを安全に組み合わせることができます。さらに、これらの戦略は、アップグレードグループのメンバーが昇格する順序に影響を与える可能性があります。詳細については、「7.1グループ内の異なるバージョンの互換性のあるメンバー」を参照してください。
グループをオフラインでアップグレードできる場合、具体的なアップグレードプロセスについては、「7.2。グループレプリケーションのオフラインアップグレード」を参照してください。グループをオンラインでアップグレードする必要がある場合（通常、実稼働環境ではオンラインアップグレードが必要です）、最小のダウンタイムでグループをアップグレードするさまざまな方法については、「7.3。グループレプリケーションのオンラインアップグレード」を参照してください。
7.1。グループ内の異なるバージョンのメンバーと互換性があります
グループレプリケーションは、MGRプラグインにバインドされているMySQLサーバーのバージョンに従ってバージョン制御されます。たとえば、メンバーがMySQLバージョン5.7.26で実行されている場合、これはMGRプラグインのバージョンです。次のステートメントを使用して、グループメンバーのMySQLServerのバージョンを確認します。
root@localhost : (none):35: > SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_VERSION |
+-------------+-------------+----------------+
| node2 | 3306 | 8.0.17 |
| node3 | 3306 | 8.0.17 |
| node1 | 3306 | 8.0.17 |
+-------------+-------------+----------------+
3 rows in set (0.01 sec)
最高の互換性とパフォーマンスを得るには、グループのすべてのメンバーが同じバージョンのMySQL Serverを実行することをお勧めします。また、同じバージョンのグループレプリケーション通信プロトコルを実行することもお勧めします。ただし、グループのオンラインアップグレード中に、グループの可用性を最大化するために、異なるMySQLServerバージョンのメンバーを同時に実行する必要がある場合があります。異なるMySQLバージョン間で一部の機能が異なる場合があるため（たとえば、新しいバージョンは一部の新機能をサポートしているが、古いバージョンはサポートしていないため、古いバージョンでサポートされている一部の機能は新しいバージョンで削除されます） 、この場合、古いバージョンと新しいバージョンの間に非互換性の問題がある可能性があります。この場合、異なるバージョンのMySQL Serverをグループに構成すると、非推奨の機能に依存しているメンバーが失敗したり、新しいバージョンの新機能をサポートしていない古いバージョンで問題が発生したりする可能性があります。
これらの問題を防ぐために、グループレプリケーションは、異なるMySQLServerバージョンで実行されているグループメンバーのグループを安全で互換性のあるものにするためのいくつかの互換性戦略をサポートしています。グループメンバーは、これらのポリシーを適用して、新しく追加されたサーバーとグループの既存のメンバーとの間の操作のセキュリティを確保できる選択に応じて、グループに通常参加するか、読み取り専用モードでグループに参加するか、グループに参加しないかを決定します。グループへのローリングアップグレードを実行する場合、各メンバーは最初にグループを離れ、次に新しいバージョンにアップグレードしてから、新しいバージョンでグループに再度参加する必要があります。このとき、グループのメンバーは、新しいバージョンに対応するポリシーと一致する必要があります（ポリシーは、グループメンバーのアップグレード前に適用されたポリシーとは異なる場合があります）。
グループに参加しようとしているメンバーによって適用される互換性ポリシーは次のとおりです。
MySQLサーバーのバージョンが、グループ内の既存のグループメンバーによって実行されている最小バージョンよりも低い場合、サーバーはグループに参加できません。
MySQLサーバーのバージョンが、グループの既存のメンバーによって実行されている最小バージョンと同じである場合、サーバーは通常（そして許可して）グループに参加します。
サーバーがグループに参加した後、サーバーが実行するMySQL Serverのバージョンが、グループ内の既存のグループメンバーが実行する最小バージョンよりも高い場合、メンバーは読み取り専用モードのままになります（グループがシングルプライマリモードで実行されている場合、新しく追加されたメンバーはすべての場合において、デフォルトは読み取り専用です。グループがマルチプライマリモードで実行されている場合、新しく追加されたメンバーは読み取り/書き込みモードである可能性があります。
MySQL 8.0.17以降を実行しているサーバーは、互換性を確認するときにリリースのパッチバージョンを考慮します（たとえば、バージョン番号は8.0.17で、8.0はメジャーバージョンを表し、17はパッチバージョンを表します。これはマイナーとも呼ばれます。バージョン）。MySQL8.0.16以下またはMySQL5.7を実行しているサーバーは、メジャーバージョンのみを考慮します（たとえば、バージョン番号は8.0.16で、8.0はメジャーバージョンです）。すべてのメンバーがバージョン8.0.13を実行しているグループを想定すると、グループに参加しようとしているサーバーによって適用される互換性ポリシーは次のとおりです。
MySQL5.7.xを実行しているサーバーはグループに参加できません。
MySQLバージョン8.0.16を実行しているサーバーは、通常どおりグループに参加できます（ここでは、グループの既存のメンバーが考慮している文字列8.0と一致するメジャーバージョンの文字列8.0のみが考慮されているため）。
MySQLバージョン8.0.17を実行しているサーバーはグループへの参加が許可されますが、読み取り専用モードのままになります（新しく追加されたサーバーは、パッチバージョン17である8.0.17も考慮し、グループ内の既存のメンバーは文字列のみを考慮するため） 8.0）。
5.7.27より前のバージョンのMySQLを持つサーバーがグループに参加すると、各グループメンバーのMySQLメジャーバージョン番号が小さいかどうかを確認するために、すべてのグループメンバーのバージョンがチェックされることに注意してください。したがって、上記の例と互換性ポリシーに従って、グループのいずれかのメンバーがMySQL 8.0バージョンを実行している場合、このチェックは失敗し、グループの他のメンバーがすでにMySQLを実行している場合でも、5.7.27より前のバージョンのMySQLのサーバーはグループに参加できなくなります。バージョン5.7では、グループに参加することもできません。MySQL 5.7.27バージョン以降、グループに参加するサーバーは、グループの既存のメンバーによって実行されている最小メジャーバージョンのみをチェックします。このようにして、MySQL 5.7.27以降で実行されているサーバーは、混合MySQL5.7.xを使用するサーバーに参加できます。バージョンメンバーのグループ。
MySQL Serverのバージョンが異なるマルチマスターモードグループでは、グループレプリケーションにより、MySQL8.0.17以降を実行しているメンバーの読み取り/書き込みおよび読み取り専用ステータスが自動的に管理されます。メンバーがグループを離れると、現在の最低バージョンを実行しているメンバーは自動的に読み取り/書き込みモードに設定されます。group_replication_switch_to_multi_primary_mode（）UDFをオンラインで使用してシングルプライマリモードグループをマルチプライマリモードに変更すると、グループレプリケーションによってメンバーが自動的に正しいモードに設定されます。MySQL Serverバージョンを実行しているメンバーがグループ内の最低バージョンよりも高い場合、自動的に読み取り専用モードに設定され、最低バージョンを実行しているメンバーは自動的に読み取り/書き込みモードに設定されます。
7.1.1。グループメンバーをアップグレードする
オンラインアップグレードプロセス中に、グループがシングルマスターモードの場合、アップグレード操作を実行するメンバーがオフラインになった後（アップグレード操作を実行するグループのメンバーはオフラインである必要があり、アップグレード操作を実行しないグループのメンバーはオフラインである必要はありません）、グループは実行されません。アップグレードグループのメンバーは、「1.3.1シングルマスターモード」で説明されている選択戦略に従って、新しいプライマリノードを選択します。プライマリノードを常に変更しないでおく必要がある場合（アップグレード自体を実行している場合を除く）、最初に他のすべてのグループメンバーでアップグレードを実行し、最後にプライマリノードでアップグレードを実行する必要があることに注意してください（プライマリノードがアップグレードされると、プライマリノードはオフラインになります。 、したがって、新しいプライマリノードがグループ内で再選出されます。アップグレードが完了した後、プライマリノードを元のメンバーのままにしておきたい場合は、group_replication_set_as_primary（）UDFを使用してプライマリノードとして再指定できます。
グループがマルチプライマリモードの場合、アップグレードされたメンバーは読み取り専用モードになり、グループに再参加するため、アップグレードプロセス中に通常の書き込み操作を実行できるグループメンバーはますます少なくなります（これは、新しいバージョンが古いバージョンでは機能を正常にコピーできません）。すべてのメンバーがMySQL8.0.17以降のバージョンにアップグレードされると、メンバーは自動的に読み取り/書き込みモードに戻ります。ただし、以前のバージョンでは、アップグレードの完了後に、各グループメンバーのシステム変数super_read_onlyとread_onlyを手動でOFFに設定（読み取り/書き込みモードを設定）して、メインノードにする必要があります。
注：MySQL 8.0.17以降の新旧バージョンの比較では、比較時にマイナーバージョン番号を考慮する必要があります。バージョン8.0.16以前では、バージョンを比較するときにメジャーバージョン番号のみが考慮されます。
グループメンバーのアップグレードプロセス中にアップグレードロールバックメンバーを作成する必要がある場合、またはグループに新しいメンバーを追加する必要がある場合、緊急時に、MySQL Serverのバージョンがグループ内の最低バージョンよりも低いメンバーにグループへの参加を許可できます（グループを使用）システム変数group_replication_allow_local_lower_version_joinをコピーして、通常の互換性ポリシーを上書きします。このシステム変数をONに設定しても、新しいメンバーはグループと互換性がないことに注意してください。したがって、このシステム変数は、特定の状況でのみ注意して使用できます。 「8.グループ複製システム変数」のgroup_replication_allow_local_lower_version_joinシステム変数の説明を参照してください。
7.1.2。グループコピー通信プロトコルバージョン
グループレプリケーションで使用されるグループ通信プロトコルのバージョン番号は、グループメンバーのMySQL Serverバージョン番号と必ずしも同じではありません（たとえば、MySQL Server 8.0.17で使用される通信プロトコルバージョンは8.0.17ではなく8.0.16であり、プロトコルバージョンはこのグループで現在サポートされている最も低いMySQLServerバージョン、MySQLバージョン5.7.14は圧縮メッセージをサポートし、MySQLバージョン8.0.16はメッセージセグメンテーションをサポートします。グループの通信プロトコルバージョンを表示するには、グループの任意のメンバーで次のステートメントを実行してクエリを実行できます。
root@localhost : (none):35: > SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16 |
+------------------------------------------------+
1 row in set (0.00 sec)
注：group_replication_get_communication_protocol（）UDFによって返されるグループ通信プロトコルバージョンは、グループで現在サポートされているMySQL Serverの最低バージョンを表します。group_replication_set_communication_protocol（）UDFを使用してグループ通信プロトコル構成を実行する場合、最終的な実効値は関数に渡される値と異なる場合があります。例：この関数に渡される値は8.0.17であり、最終的な実効値は8.0.16です。
レプリケーショングループのすべてのメンバーが新しいMySQLServerバージョンにアップグレードされた場合、以前のバージョンのメンバーがグループに参加できるようにする必要がある場合に備えて、グループレプリケーション通信プロトコルバージョンは自動的にアップグレードされません。新しいバージョンにアップグレードした後、古いバージョンのサーバーをサポートする必要がないと判断され、新しいバージョンのいくつかの追加機能も使用する場合は、group_replication_set_communication_protocol（）UDF関数を使用して、グループ通信プロトコルバージョン（グループ内の全員）をアップグレードできます。グループ通信プロトコルのバージョン操作を変更できるのは1人のメンバーのみです）。詳細については、「4.1.4グループの通信プロトコルバージョンの設定」を参照してください。
7.2。グループレプリケーションのオフラインアップグレード
グループレプリケーションのオフラインアップグレードを実行するには、グループのすべてのメンバーをグループから1つずつ削除する必要があります。グループがオフラインであることを確認した後、各サーバーでバージョンアップグレードを実行します。すべてのサーバーバージョンをアップグレードした後、通常どおりグループを再起動します。マルチマスターモードグループでは、グループメンバーを任意の順序で削除および閉じることができます。シングルマスターモードグループでは、最初に読み取り専用メンバーのサーバーを1つずつ削除して閉じ、最後にメインノード（書き込みノード）メンバーのサーバーを閉じる必要があります。グループからメンバーを削除してMySQLServerをシャットダウンする方法については、「7.3.2。グループレプリケーションメンバーのアップグレード」を参照してください。
グループ内のすべてのメンバーが新しいバージョンに正常にアップグレードされた後、グループが再起動されると、これらのメンバーは新しいバージョンのグループ複製通信プロトコルを使用して接続します。この時点で以前のバージョンのサーバーをグループに参加させる必要がある場合は、group_replication_set_communication_protocol（）UDFを使用して、グループ通信プロトコルのバージョンを古いバージョンでサポートされている通信プロトコルのバージョン番号にダウングレードできます（または古いバージョンのMySQLサーバーのバージョン番号を直接入力します）
7.3。グループレプリケーションのオンラインアップグレード
実行中のグループでバージョンアップグレードを実行する必要があり、アップグレードプロセス中にグループが外部にサービスを提供することを確認する必要がある場合は、正しいアップグレード方法を採用する必要があります。このセクションでは、オンラインアップグレードグループを実行する方法のいくつかの方法を紹介します。
7.3.1。オンラインアップグレードに関する注意事項
グループをオンラインでアップグレードする場合は、次の点を考慮する必要があります。
グループメンバーのアップグレード方法に関係なく、グループメンバーがアップグレードされてグループに再参加するまで、メンバーに対して書き込み操作を実行することは禁止されています。
メンバーがグループレプリケーションを停止すると、システム変数super_read_onlyは自動的にオンに設定されますが、この変更された値は永続的ではありません。つまり、変更された値は、サーバーの再起動後に構成ファイルの設定またはデフォルト値によって上書きされます。
MySQL5.7.22またはMySQL8.0.11のメンバーが、MySQL 5.7.21以下を実行しているグループに参加しようとすると、MySQL 5.7.21がシステム変数lower_case_table_namesの値を送信しないため、失敗します。
7.3.2。グループレプリケーションメンバーをアップグレードする
このセクションでは、グループメンバーをアップグレードするために必要な手順について説明します。このプロセスは、「7.3.3グループコピーオンラインアップグレード方法」の一部です。グループのすべてのメンバーをアップグレードする方法は一般的ですが、グループはシングルマスターモードまたはマルチマスターモードで実行されているため、グループメンバーがアップグレードされて再参加する順序に影響することに注意してください。
グループメンバーをアップグレードするプロセスには、グループからメンバーを削除し、選択したメンバーのアップグレード方法に従ってアップグレードを実行してから、アップグレードしたメンバーをグループに再度追加することが含まれます。シングルマスターモードグループのメンバーをアップグレードする場合は、最初に読み取り専用ノードをアップグレードしてから、読み取り/書き込みノード（プライマリノード）をアップグレードすることをお勧めします。読み取り専用ノードの前に読み取り/書き込みノードをアップグレードする必要がある場合は、古いノードを選択する必要があります。バージョンの他のメンバーは、新しいメインノードとして機能します。したがって、作業負荷を軽減するために、通常、読み取りノードと書き込みノードを最後にアップグレードすることをお勧めします。
グループメンバーのアップグレード：
クライアントを使用して、アップグレードするグループメンバーにログインし、STOP GROUP_REPLICATIONステートメントを実行してグループの複製を停止してから、performance_schema.replication_group_membersテーブルをチェックして、メンバーがOFFLINE状態にあることを確認します（現時点では、テーブルには1つの行しかないことに注意してください）。 、およびこの行レコードのMEMBER_STATEフィールド値はOFFLINEです）。
システム変数group_replication_start_on_boot = 0を設定して、再起動時にメンバーがグループに自動的に参加することを禁止することにより、アップグレードおよび構成操作が完了した後、手動で安全にメンバーをグループに再参加させます。注：アップグレードを実行するメンバーがシステム変数group_replication_start_on_boot = 1を設定した場合、アップグレード操作が失敗すると、失敗したメンバーはサーバーの再起動時に自動的にグループに参加しようとします。
グループメンバーのMySQLServerプロセスを停止します。たとえば、サーバーが配置されているサーバーでmysqladmin shutdownコマンドを使用するか、データベースにログインし、shutdownステートメントを使用して、アップグレードが必要なグループメンバーのサーバープロセスを停止します。このとき、グループの他のメンバーは影響を受けることなく実行を継続します。
in-situを使用するか（mysql_upgradeコマンドを使用してデータディクショナリメソッドをアップグレードする）、または事前にインストールおよび構成された新しいバージョンのサーバーを使用して論理派生物をアップグレードします。アップグレード後にサーバーを再起動すると、システム変数group_replication_start_on_bootが0に設定されているため、グループレプリケーションが自動的に開始されてグループに再参加することはありません。そのため、グループに再参加するには手動操作が必要です。
メンバーのアップグレードが完了したら、システム変数group_replication_start_on_bootを1に設定して、次回の再起動後にメンバーが自動的にグループに再参加できるようにする必要があります。
クライアントを使用してアップグレードされたサーバーにログインし、STARTGROUP_REPLICATIONステートメントを実行してグループレプリケーションを開始します。サーバーをグループに再参加させます。この時点で、アップグレードされたメンバーでグループレプリケーションのメタデータの準備ができているため、通常、グループレプリケーションを再構成する必要はありません。ただし、グループ内の最新のトランザクションに追いつく必要があります。グループ内の最新のトランザクションに追いつくと、このグループのオンラインメンバーになります。注：サーバーのアップグレードにかかる時間が長いほど（つまり、グループを離れるのにかかる時間が長くなるほど）、サーバーとグループのデータの差が大きくなり、データをグループに追加し直すのに必要な時間が長くなります。より多く（追いつくためにより多くのトランザクションがあるかもしれないので）。
アップグレードされたサーバーがグループに参加するときに、グループのメンバーが古いバージョンのMySQLサーバーを実行していることが判明した場合、アップグレードされたサーバーは、グループに再参加するときにシステム変数super_read_onlyをonに設定します。これにより、すべてのメンバーが新しいバージョンにアップグレードされる前に、新しくアップグレードされたサーバーに新しいデータが書き込まれないようにすることができます（新しいバージョンのサーバーに書き込まれたデータが古いバージョンのサーバーと互換性がなくなるのを防ぎます）。マルチマスターモードのグループでは、グループがアップグレードされて外部にサービスを提供する準備ができたら、書き込み可能なマスターモードにする予定のメンバーを読み取り/書き込みモードに設定する必要があります。MySQL 8.0.17以降、グループのすべてのメンバーが同じバージョンにアップグレードされると、すべてのメンバーが自動的に読み取り/書き込みモードに設定されます。ただし、以前のバージョンでは、読み取りおよび書き込み操作を実行する必要がある各メンバーを読み取りおよび書き込みモードに手動で設定する必要があります。次のステートメントで設定します。
root@localhost : (none):30: > SET GLOBAL super_read_only=OFF; set global read_only=OFF;
Query OK, 0 rows affected (0.00 sec)
7.3.3。グループレプリケーションのオンラインアップグレード方法
グループレプリケーションのオンライン更新にはいくつかのオプションがあり、実際の状況に応じて選択できます。
7.3.3.1。グループ内のローリングアップグレード
グループ内のローリングアップグレード：グループメンバーを1つずつグループから削除し、インプレースアップグレードを実行し（データを移行する必要はなく、サーバーを交換する必要もありません）、アップグレードの完了後にグループに再参加することを指します。アップグレードプロセス中、グループは外部に読み取りおよび書き込みサービスを提供できますが、グループから削除されてアップグレードを実行するメンバーは、アップグレードプロセス中にワークロードを実行しません（読み取り専用または読み取り/書き込みサービスは提供されません）。アップグレードが完了した後、グループに再参加するときに、グループ内にバージョン番号の小さいメンバーがいる場合、読み取り専用モードでグループに再参加します（現時点では読み取り専用サービスのみが提供されます）。新しく追加されたメンバーが将来、読み取り専用モードから読み取り/書き込みモードに変更する必要があるかどうかは、グループがシングルマスターモードで実行されているかマルチマスターモードで実行されているかによって異なります。
シングルプライマリモード：グループ内のローリングアップグレード方法は、シングルプライマリモードグループに非常に適しています。シングルプライマリモードでは、ローリングアップグレードを実行すると、セカンダリノード（読み取り専用ノード）が1つずつアップグレードされ、プライマリノード（読み取り/書き込みノード）がアップグレードされます。最後にアップグレードを実行して、アップグレードプロセス全体で、再選をできるだけ回避できるようにします。もちろん、メインノードの最終アップグレードでは、マスターを再選することは避けられませんが、この推奨される順序に従って、再選は1回だけ発生します。つまり、メインノードがグループから削除され、アップグレードが実行されたときにトリガーされます。マスターを一度再選します。最後のメンバー（つまり、前のプライマリノード）がアップグレードされると、group_replication_set_as_primary（）UDFを使用して、それをプライマリノードとして再割り当てできます。もちろん、どのグループメンバーがメインノードであるかを気にしない場合は、UDFを使用せずにメインノードを再割り当てできます。シングルマスターモードでのマスター選択方法については、「1.3.1シングルマスターモード」を参照してください。
マルチプライマリモード：マルチプライマリモードグループの場合、複数のメインノード（読み取りノードと書き込みノード）が存在する場合があります。グループ内でローリングアップグレードを使用する場合、特定の更新順序ルールはありません（メンバーの更新順序は実際の状況に応じて決定できます）。ただし、グループ内のすべてのメンバーが最新バージョンに更新される前に、更新されたメンバーがグループに再参加すると、強制的に読み取り専用モードに設定されます（グループ内に下位バージョンのメンバーが存在するため、システム変数super_read_only = ONを設定します。注：super_read_only = ONの場合、read_onlyは自動的にONに設定されますが、super_read_only = OFFの場合、read_onlyは自動的にOFFに設定されません）。これは、マルチマスターモードグループ内の複数のノードが読み取りサービスと書き込みサービスを同時に提供できるためです。したがって、この場合、グループ内のすべてのメンバーが最新バージョンに更新されるまで、グループの書き込み可能性は徐々に低下します。グループ内のすべてのメンバーが最新バージョンに更新され、MySQL Serverのバージョン番号が8.0.16未満の場合、読み取り専用モードのグループメンバーになります。システム変数super_read_only = OFF、read_only = OFFを手動で設定して、のみをオフにする必要があります。読み取り（読み取り/書き込みモードに戻ります）。MySQL Serverのバージョン番号が8.0.17以上の場合、すべてのメンバーが新しいバージョンに更新された後、システム変数super_read_only = OFF、read_only = OFFが自動的に設定され、読み取り専用がオフになります（読み取り/書き込みモードに戻ります）。マルチマスターモードでのバージョン互換性については、「1.3.2.3。バージョン互換性」を参照してください。
グループ内のバージョンの互換性と、アップグレードプロセス中のグループの動作への影響の詳細については、「7.1。グループ内の異なるバージョンの互換性のあるメンバー」を参照してください。
PS：グループ内のローリングアップグレードプランでは、アップグレードが完了した後、グループメンバーは元のグループに再び参加します。
7.3.3.2。移行とローリングアップグレード
移行ローリングアップグレード：グループメンバーがグループから1つずつ削除され、アップグレードが実行された後、元のグループに再参加せず、アップグレードされたメンバーを使用して2番目のグループ（新しいグループ）を作成することを指します。マルチマスターモードで実行されているグループの場合、このプロセス中にメインノード（読み取りノードと書き込みノード）の数が徐々に減少するため、書き込みの可用性が低下します。ただし、シングルプライマリモードで実行されているグループの場合、これはグループの書き込み可用性には影響しません（ただし、グループの最後で読み取り/書き込みノードがアップグレードされると、アプリケーションは古いグループと新しいグループの間で書き込み要求の切り替えを実行する必要があり、この時点でアプリケーションが影響を受けます）。
グループをアップグレードする過程で、古いバージョンを実行しているグループは常にオンラインであるため（外部に読み取り/書き込みおよび読み取り専用サービスを継続的に提供します）、更新されたバージョンのメンバーで構成される新しいグループはアップグレードプロセスに追いつく必要があります。グループ内で新しく作成されたトランザクション。したがって、新しいグループのメンバーをスレーブライブラリとして選択し、古いグループのメインノード（読み取り/書き込みノード）との非同期マスタースレーブレプリケーションチャネルを確立して、最新のデータに追いつく必要があります。非同期レプリケーションチャネルを介してデータに追いつく際の事故を回避するには、グループレプリケーションと新旧グループ間のマスタースレーブレプリケーションに関連するシステム構成パラメータが完全に一貫していることを確認する必要があります。シングルマスターモードで実行されているグループの場合、新しいグループのスレーブライブラリのメンバーは、新しいグループのプライマリノード（読み取り/書き込みノード）である必要があります。マルチマスターモードで実行されているグループの場合、新しいグループのスレーブライブラリのメンバーは新しいものにすることができます。グループの任意のメンバー（読み取り/書き込みノード）。
アップグレードプロセス全体は、おおまかに次のとおりです。
古いバージョンを実行している元のグループからメンバーを1つずつ削除します。「7.3.2。グループコピーメンバーのアップグレード」を参照してください。
除外されたグループのメンバーで実行されているMySQLServerのバージョンをアップグレードします。アップグレード手順については、「MySQLパフォーマンス最適化ピラミッドの式」を参照してください。第2章MySQLで一般的に使用される2つのアップグレード方法。
グループのメンバーを新しいバージョンにアップグレードして、新しいグループを作成します。新しいグループを展開する手順については、「2。グループコピーのインストールと展開」で詳しく説明しています。古いグループが実行されているため、新しいグループに新しいグループ名を付け、最初にアップグレードされたメンバーを使用して新しいグループをガイドする必要があります。その後、アップグレードされたメンバーは新しいグループに参加できます。
古いグループと新しいグループの間に非同期レプリケーションチャネルを設定します。古いグループのメインノードを非同期レプリケーションのマスターライブラリとして設定し、新しいグループのメインノードをGTIDレプリケーションのスレーブライブラリとして構成します。
アプリケーションを新しいグループにリダイレクト（切り替え）する前に、メンバーに障害が発生したときに新しいグループが正常に応答できるように、新しいグループに適切な数のグループメンバーがあることを確認する必要があります。新しいグループの任意のメンバーのperformance_schema.replication_group_membersテーブルからグループメンバービューにクエリを実行すると、古いグループと新しいグループのグループサイズを表示できます。この情報を確認した後、古いグループへのデータ書き込みをブロックできます（古いグループと新しいグループの違いを確認する必要があります）。時間間の非同期レプリケーション遅延。この手順は、遅延が大きくない場合に実行できます）、新しいグループが古いグループのすべてのデータに追いつくまで、新しいグループが古いグループの最新のデータに追いつくのを待ってから、アプリケーションを新しいグループに切り替えます。 、古いグループと新しいグループ間の非同期レプリケーション接続を削除します。最後に、古いバージョンのすべてのグループメンバーをアップグレードします。アップグレードが完了したら、それらを1つずつ新しいグループに追加します。
PS：ローリングアップグレードプランを移行します。グループメンバーがアップグレードされた後、それらは新しいグループを形成し、サーバー（ホスト）は元のグループのままです。
7.3.3.3。レプリカローリングアップグレード
ローリングコピーのアップグレード：「グループ内のローリングアップグレード」と「ローリング移行アップグレード」の2つのスキームと比較して、グループメンバーはグループからグループを削除する必要がなく、代わりにバックアップツールを使用してグループ内のデータコピーを1つにコピーします。新しいサーバーグループで、アップグレードを1つずつ実行し、2番目のグループ（新しいグループ）を作成します。アップグレード中、古いグループは引き続きオンラインでサービスを提供するため、新しいグループと古いグループの間の増分データを新しいグループと古いグループの間で渡す必要があります。データ同期用の非同期レプリケーションチャネルを確立します（古いグループと新しいグループの間に非同期レプリケーションチャネルを作成するための要件については、「7.3.3.2。移行とローリングアップグレード」を参照してください）。新しいグループが古いグループの最新データに追いつくと、それが適用されます。プログラムへのアクセスは新しいグループに切り替えられます。マルチマスターモードで実行されているグループの場合、アップグレードプロセス中にプライマリノード（読み取りノードと書き込みノード）の数が減らないため、書き込みの可用性に影響はありません（したがって、このアップグレード方法はマルチマスターモードで実行されているグループに非常に適しています） 。シングルプライマリモードで実行されているグループの場合、書き込みの可用性も影響を受けません。
アップグレードプロセス全体は、おおまかに次のとおりです。
新しいバージョンのサーバーパッケージを使用して、新しいサーバーを初期化してインストールします。メンバーに障害が発生したときに、新しいバージョンのメンバーの数が正常に応答できることを確認する必要があります。現時点では、新しいバージョンのサーバーにグループを作成する必要はありません。新しいバージョンのパッケージを使用してデータベースサーバーを初期化およびインストールし、サーバーが正常に起動できることを確認してください。
元のグループのメンバーから既存のデータをバックアップします（完全バックアップ）。バックアップの詳細な手順については、「4.6。バックアップデータを使用して失敗したメンバーを復元するか、グループレプリケーションで新しいメンバーを拡張する」を参照してください。
バックアップデータを使用して、新しいグループを作成するサーバーに復元し、インプレースアップグレードを実行します。
サーバーを新しいバージョンにアップグレードして、新しいグループを作成します。新しいグループを展開する手順については、「2。グループコピーのインストールと展開」で詳しく説明しています。古いグループが実行されているため、新しいグループに新しいグループ名を付け、最初にアップグレードされたサーバーを使用して新しいグループをガイドする必要があり、後続のアップグレードされたサーバーが新しいグループに参加できることに注意してください。
古いグループと新しいグループの間に非同期レプリケーションチャネルを設定します。古いグループのメインノードを非同期レプリケーションのマスターライブラリとして設定し、新しいグループのメインノードをGTIDレプリケーションのスレーブライブラリとして構成します。
新しいグループのデータが古いグループのレプリケーションと比較して十分に遅延すると、アプリケーションの切り替えを実行でき（アプリケーションアクセスを新しいグループにリダイレクト）、古いグループと新しいグループ間の非同期レプリケーションチャネルを削除します（詳細アプリケーションの切り替え要件については、「7.3.3.2。移行ローリングアップグレード」を参照してください。
PS：コピーローリングアップグレードスキーム。グループメンバーがアップグレードされた後、グループメンバーとサーバー（ホスト）はまったく新しいものになります。
|作者について
LuoXiaobo・データベーステクノロジーエキスパート
「千の黄金のレシピ-MySQLパフォーマンス最適化ピラミッドルール」の著者の1人。MySQLアーキテクチャに精通し、オープンソーステクノロジーに特化するなど、データベース全体のチューニングに精通し、オープンソーステクノロジーの推進に熱心であり、オンラインおよびオフラインで多くのパブリックデータベーストピック共有を行い、100近くのデータベース関連の研究記事を公開しています。
参考文献
グループレプリケーションの日常業務-トランザクションの一貫性の保証| MySQL8.0グループレプリケーションの包括的な理解
グループレプリケーションのルーチン操作-グループをオンラインで構成する| MySQL8.0グループレプリケーションの包括的な理解
全文は終わりました。
MySQL8.0をお楽しみください:)
TeacherYeの「MySQLCoreOptimization」クラスがMySQL8.0にアップグレードされました。コードをスキャンして、MySQL8.0の練習の旅を始めてください。