導入
MySQLレプリケーションは、1つのデータベースから別のデータベースへのデータと操作の信頼性のあるミラーリングを提供します。従来のレプリケーションは、プライマリサーバーがデータベースの書き込み操作を受け付けるように構成され、セカンダリサーバーがプライマリサーバーのログから操作をコピーして適用するというものです。これらのセカンダリサーバーは読み取りに使用できますが、通常はデータの書き込みを実行できません。
グループレプリケーションは、より柔軟で耐障害性のあるレプリケーションメカニズムを実装する方法です。このプロセスでは、データが正しくコピーされるように各サーバーが関与するサーバープールを確立します。プライマリサーバーに問題が発生した場合、メンバー選挙がグループから新しいプライマリを選択できます。これにより、残りのノードが問題に直面しても動作を継続できます。メンバーシップの交渉、障害検出、およびメッセージ配信は、Paxosコンセンサスアルゴリズムの実装によって提供されます。
このチュートリアルでは、Ubuntu 20.04サーバーのセットを使用してMySQLグループレプリケーションを設定します。MySQLでグループレプリケーションを展開するために必要な最小のMySQLインスタンス数は3ですが、最大は9です。このチュートリアルを進める中で、グループを単一プライマリまたはマルチプライマリレプリケーショングループとして設定するオプションがあります。
注意: データベースサーバーは、レプリケーションセットアップにおいて2つの役割のいずれかを持つことができます。ユーザーはデータを書き込むことができるプライマリインスタンス（またはソースインスタンス）であるか、レプリカ（またはセカンダリインスタンス）であり、ソース上のすべてのデータのコピーを保存します。歴史的に、これらの役割はそれぞれマスターインスタンスとスレーブインスタンスと呼ばれてきました。しかし、2020年7月に公開されたブログ投稿では、MySQLチームがこの用語の否定的な起源を認め、データベースプログラムとそのドキュメントを更新して包括的な言語を使用する取り組みを発表しました。
ただし、これは継続的なプロセスです。MySQLのドキュメントおよびプログラムのバージョン8の多くのコマンドは、レプリケーショントポロジ内のサーバーをプライマリおよびそのセカンダリ（またはソースおよびそのレプリカ）として参照するように更新されていますが、否定的な用語がまだ現れる場所があります。このガイドでは可能な限り包括的な用語をデフォルトにしますが、古い用語が避けられないいくつかの場所があります。
前提条件
このガイドを完了するには、次のものが必要です：
sudo権限を持つ非ルート管理ユーザーを持つ3台のUbuntu 20.04サーバー。各サーバーにはUFWで構成されたファイアウォールがあります。Ubuntu 20.04の初期サーバー設定ガイドに従って、各サーバーをセットアップします。- 各サーバーにMySQLがインストールされています。このガイドでは、この執筆時点でデフォルトのUbuntuリポジトリから利用可能な最新バージョンのMySQL（バージョン8.0.28）を使用していると仮定しています。すべてのサーバーにこれをインストールするには、各マシンのUbuntu 20.04にMySQLをインストールする方法ガイドに従ってください。
わかりやすくするために、このガイドでは3つのサーバーをメンバー1、メンバー2、およびメンバー3と呼びます。このガイド全体での例では、これらのメンバーのIPアドレスは次のとおりです：
| Member | IP address |
|---|---|
| member1 | 203.0.113.1 |
| member2 | 203.0.113.2 |
| member3 | 203.0.113.3 |
メンバー1で実行する必要があるコマンドは、次のように青い背景で表示されます：
同様に、メンバー2で実行する必要があるコマンドは、次のように赤い背景で表示されます：
そして、メンバー3で実行する必要があるコマンドは、次のように緑の背景で表示されます：
最後に、3つのサーバーのそれぞれで実行する必要があるコマンドは、標準の背景で表示されます：
ステップ1 — MySQLグループを識別するUUIDの生成
MySQLグループレプリケーションの設定を構成する前に、作成するMySQLグループを識別するために使用できるUUIDを生成する必要があります。
member1で、uuidgenコマンドを使用してグループのための有効なUUIDを生成します：
Output168dcb64-7cce-473a-b338-6501f305e561
受け取った値をコピーしてください。これは、サーバープールのグループ名を構成する際にまもなく参照する必要があります。
ステップ2 — MySQL構成ファイルでグループレプリケーションの設定
これで、MySQLの構成ファイルを変更する準備が整いました。お好みのテキストエディターを使用して、各MySQLサーバーのメインMySQL構成ファイルを開きます。ここでは、nanoを使用します：
Ubuntuでは、MySQLはさまざまな設定変更を定義するために使用できる複数の異なるファイルがインストールされています。デフォルトでは、my.cnfファイルはサブディレクトリから追加のファイルをソースにするためだけに使用されます。自分自身の設定を追加するには、!includedir行の下に設定を追加する必要があります。これにより、含まれているファイルからの設定を上書きできます。
始めるには、[mysqld]ヘッダーを含めて新しいセクションを開始し、次に、次の例に示すように、グループレプリケーションを有効にするために必要な設定を追加します。これらの設定は、公式のMySQLドキュメントに記載されているグループレプリケーションに必要な最小限の設定から変更されていることに注意してください。loose-接頭辞は、MySQLが優雅に認識しないオプションを処理し、失敗せずに扱うためのものです。これらの設定のいくつかをすぐに埋め込んでカスタマイズする必要があります:
. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""
# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
# Host specific replication configuration
server_id =
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""
これらの設定オプションをより明確に説明するために、以下のサブセクションに分割されています。デプロイメントグループを展開する方法に関する選択肢がいくつか提示される場合や、独自の構成に固有の詳細を入力する必要がある場合があるため、これらを注意深く読んでください。
ボイラープレートグループレプリケーション設定
最初のセクションには、修正不要のグループレプリケーションに必要な一般設定が含まれています:
. . .
# 一般的なレプリケーション設定
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .
MySQLのグループレプリケーションの特定の要件の1つは、データをInnoDBストレージエンジンに保存する必要があります。 MySQLのドキュメントでは、このセクションの最初のコメント解除された行のように、エラーを引き起こす可能性のある他のストレージエンジンの使用を明示的に無効にすることを推奨しています。
残りの設定は、グローバルトランザクションIDをオンにし、グループレプリケーションに必要なバイナリログを設定し、グループのSSLを設定します。 この構成では、リカバリとブートストラップを支援する他のいくつかの項目も設定されます。 このセクションでは何も変更する必要はなく、3つのサーバーすべてで同一である必要があるため、追加した後に移動できます。
共有グループレプリケーション設定
2番目のセクションでは、グループの共有設定を設定します。 これをカスタマイズしてから、各ノードで同じ設定を使用する必要があります。 特に、前の手順で作成したグループのUUID、承認されたグループメンバーのリスト、およびグループに参加する際に初期データを取得するために連絡を取るシードメンバーを追加する必要があります。
loose-group_replication_group_nameを、以前にuuidgenコマンドで生成したUUID値に設定してください。UUIDを空の二重引用符の間に配置することを確認してください。
次に、loose-group_replication_ip_whitelistを、MySQLサーバーのすべてのIPアドレスのリストに設定し、カンマで区切ってください。 loose-group_replication_group_seeds設定は、ホワイトリストとほぼ同じである必要がありますが、それぞれのメンバーの末尾に指定されたグループレプリケーションポートを追加する必要があります。このガイドでは、推奨されるグループレプリケーションポート33061を使用してください。
. . .
# 共有レプリケーショングループの設定
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .
このセクションは、各MySQLサーバーで同じである必要があるため、注意してコピーしてください。
単一プライマリまたはマルチプライマリの選択
次に、single-primaryまたはmulti-primaryグループを構成するかどうかを決定する必要があります。単一プライマリ構成では、MySQLは書き込み操作を処理するために単一のプライマリサーバー（ほとんどの場合、最初のグループメンバー）を指定します。マルチプライマリグループでは、グループのメンバーのどれでも書き込みを実行できます。
loose-group_replication_single_primary_modeおよびloose-group_replication_enforce_update_everywhere_checksディレクティブをコメント解除して、マルチプライマリグループを設定します。これにより、マルチプライマリグループが設定されます。単一プライマリグループの場合は、これらの2行をコメントのままにしてください：
. . .
# 単一またはマルチプライマリモード？マルチプライマリモードを使用する場合は、これらの2行のコメントを解除してください
# ここで、どのホストでも書き込みを受け入れることができます
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .
これらの設定は、MySQLサーバーの各々で同じでなければなりません。
後でこの設定を変更することができますが、その後はMySQLグループの各メンバーを再起動する必要があります。新しい構成に切り替えるには、グループ内の各MySQLインスタンスを停止し、新しい設定で各メンバーを起動し、グループレプリケーションを再起動する必要があります。これにより、データに影響はありませんが、短いダウンタイムが必要です。
ホスト固有の構成設定
4番目のセクションには、各サーバーで異なる設定が含まれています。
- サーバーID
- バインドするアドレス
- 他のメンバーに報告するアドレス
- ローカルレプリケーションのアドレスとリスニングポート
server_idディレクティブは一意の番号に設定する必要があります。 最初のメンバーでは、これを1に設定し、追加のホストごとに番号を増やします。 bind-addressとreport_hostを各サーバーのIPアドレスに設定して、MySQLインスタンスが外部接続を受け入れ、他のホストに正しくアドレスを報告できるようにします。 loose-group_replication_local_addressも、グループレプリケーションポート（33061）がIPアドレスに追加された、現在のサーバーのIPアドレスに設定する必要があります。
例として、member1の構成のこの部分は、そのサンプルIPアドレスを使用して次のようになります：
. . .
# ホスト固有のレプリケーション構成
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"
MySQLサーバーごとにこのプロセスを完了してください。 member2の構成は次のとおりです：
. . .
# ホスト固有のレプリケーション構成
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"
そして、member3の構成は次のとおりです：
. . .
# ホスト固有のレプリケーション構成
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"
編集中の構成のサーバーのIPアドレスを各ハイライトされたIPアドレスに更新してください。
完了したら、各ホストで共有レプリケーション設定が同じであり、ホスト固有の設定が各ホストにカスタマイズされていることを再確認してください。 完了したら、各ホストでファイルを保存して閉じます。 ファイルを編集するためにnanoを使用した場合は、CTRL + X、Y、ENTERを押してください。
各サーバーのMySQL構成ファイルには、MySQLグループレプリケーションのブートストラップに必要なディレクティブが含まれています。 新しい設定をMySQLインスタンスに適用するには、次のコマンドを使用してサーバーのサービスを再起動します。
それでは、各サーバーのファイアウォールルールを更新してリモートアクセスを有効にすることができます。
ステップ3 — 各サーバーのUFWルールの更新
前提として、初期サーバーセットアップガイドに従っていると仮定しています。このガイドでは、MySQLをインストールした各サーバーにファイアウォールを設定し、OpenSSH UFWプロファイルのアクセスを有効にしました。 これは重要なセキュリティ対策です。これらのファイアウォールは現在、各サーバーのauthorized_keysファイルと一致するキーを持つssh接続を除いて、サーバーの任意のポートへの接続をブロックしています。
MySQL構成ファイルでは、外部接続をデフォルトポート3306で受け付けるようにサービスを構成しました。 また、レプリケーション調整にメンバーが使用するポートを33061と定義しました。
メンバーサーバーごとに、このグループの他のメンバーとの通信を許可するために、これらのポートのアクセスを開放する必要があります。 メンバー1のメンバー2に対して、メンバー1で次のufwコマンドを実行して、これらのポートへのアクセスを開放します：
実際のメンバー2サーバーのIPアドレスに変更してください。member2_server_ipを変更してください。 次に、メンバー3に対して同じポートを開放するために、次のコマンドを実行してください：
次に、他の2つのサーバーのファイアウォールルールを更新します。 IPアドレスをそれぞれメンバー1およびメンバー3のものに変更して、メンバー2で次のコマンドを実行してください：
最後に、メンバー3でこれらの2つのコマンドを実行してください。 各サーバーの正しいIPアドレスを入力してください：
これらのUFWルールを追加した後、3つのMySQLインスタンスそれぞれが、他の2つのサーバー上でMySQLに使用されるポートへのアクセスが許可されます。
MySQLポートへのアクセスが開かれたので、レプリケーションユーザーを作成し、グループレプリケーションプラグインを有効にできます。
ステップ4 — レプリケーションユーザーの構成とグループレプリケーションプラグインの有効化
レプリケーション グループ内の他のサーバーとの接続を確立するには、各MySQLインスタンスに専用のレプリケーションユーザーが必要です。
各MySQLサーバーで、管理ユーザーでMySQLインスタンスにログインして対話セッションを開始します：
注：このセクションの各コマンドを各MySQLインスタンスで実行してください。
各サーバーにはそれぞれ独自のレプリケーションユーザーがあるため、作成プロセス中にバイナリログをオフにする必要があります。そうしないと、レプリケーションが開始されると、グループがプライマリから他のサーバーにレプリケーションユーザーを伝播しようとし、既に存在するレプリケーションユーザーと競合が発生します。次のコマンドをMySQLプロンプトから各サーバーで実行します：
これで、レプリケーションユーザーを作成するためにCREATE USERステートメントを実行できます。次のコマンドを実行して、replという名前のユーザーを作成します。このコマンドでは、レプリケーションユーザーがSSLを使用して接続する必要があることを指定します。また、このレプリケーションユーザーを作成する際に、安全なパスワードをpasswordの代わりに使用してください：
次に、新しいユーザーに対してサーバー上でのレプリケーション権限を付与します：
その後、変更を実装するために権限をフラッシュします：
その後、通常の操作を再開するためにバイナリログを再度有効にします：
次に、group_replication_recoveryチャンネルを新しいレプリケーションユーザーと関連するパスワードを使用するように設定します。その後、各サーバーはこれらの資格情報を使用してグループに認証します。
注意: MySQLのバージョンが8.0.23より古い場合は、MySQLのレガシー構文を使用してこれを設定する必要があります。
レプリケーションユーザーが設定されている場合は、group_replicationプラグインを有効にしてグループの初期化を準備できます。
次のコマンドを実行してプラグインがアクティブであることを確認してください。
最近追加されたプラグインであるため、group_replicationプラグインはリストの一番下に表示されます。
Output+----------------------------+----------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+----------------------------+----------+--------------------+----------------------+---------+
| | | | | |
| . . . | . . . | . . . | . . . | . . . |
| | | | | |
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)
この出力は、プラグインが読み込まれ、現在アクティブであることを確認しています。次のステップに進む前に、このセクションの各コマンドをMySQLの各インスタンスで実行したことを確認してください。
ステップ5 — グループレプリケーションの開始
各MySQLサーバーにレプリケーションユーザーが設定され、グループレプリケーションプラグインが有効になっているので、グループを起動できます。
最初のノードのブートストラップ
グループを起動するには、以下の手順をグループの単一のメンバーで完了してください。デモンストレーションの目的で、このガイドではこれらの手順をmember1で完了します。
グループメンバーは、最初にグループに参加する際に、既存のメンバーにレプリケーションデータや最新のメンバーリスト、その他の情報を送信することに頼っています。 そのため、初期グループメンバーを起動する際には、他のメンバーからこの情報を期待しないようにするために、やや異なる手順を使用する必要があります。
設定されている場合、group_replication_bootstrap_group変数は、メンバーに、ピアから情報を受信しないことを期待しないように指示し、代わりに新しいグループを確立し、自身を主要メンバーとして選出する必要があることを伝えます。 この変数を次のコマンドでオンにできます:
その後、初期グループメンバーのレプリケーションを開始できます:
その後、この変数をOFFに設定して、既存のグループメンバーが存在しない場合に適切な場合以外は、これをオフにします:
このサーバーを唯一のメンバーとして使用してグループを起動します。 これを確認するには、performance_schemaデータベース内のreplication_group_membersテーブル内のエントリを確認します:
このクエリは、現在のホストを表す1行を返します:
Output+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | PRIMARY | 8.0.28 | XCom |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)
MEMBER_STATEのONLINE値は、このノードがグループ内で完全に動作していることを示します。
次に、テスト用のデータベースとテーブルを作成します。 このグループにさらにメンバーが追加されると、このデータが自動的にそれらにレプリケートされます。
まず、playgroundという名前のサンプルデータベースを作成します：
次のコマンドを使用して、playground データベース内にequipment という名前の例のテーブルを作成します：
このテーブルには次の4つの列が含まれています：
id: この列には自動的に増分される整数値が含まれます。つまり、テーブルをサンプルデータでロードする際にこの列の値を指定する必要はありませんtype: この列には行が表す遊び場の機器の種類を示す文字列値が含まれますquant: この列には与えられた種類の遊び場の機器の数量を表す整数値が含まれますcolor: この列には与えられた機器の色を指定する文字列値が含まれます
また、id 列がこのテーブルの主キーとして指定されていることに注意してください。 MySQLでは、グループにレプリケートされるすべてのテーブルに、テーブルの主キーとして指定される列が必要です。
最後に、次のコマンドを実行してテーブルに1行のデータを挿入します：
データが正しく入力されたかどうかを確認するために、テーブルをクエリします：
Output+----+-------+-------+-------+
| id | type | quant | color |
+----+-------+-------+-------+
| 1 | slide | 2 | blue |
+----+-------+-------+-------+
1 row in set (0.00 sec)
このサーバーがグループのメンバーであり、書き込み機能を持っていることを確認した後、他のサーバーがグループに参加できます。
残りのノードの起動
次に、メンバー2でグループレプリケーションを開始します。 すでにアクティブなメンバーがあるため、グループをブートストラップする必要はありません。このメンバーは直ちに参加できます：
メンバー3で、同じ方法でグループレプリケーションを開始します：
再度、3つのサーバーのメンバーシップリストを確認します。 今回は、出力に3つのサーバーがリストされます：
Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | PRIMARY | 8.0.28 | XCom |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE | SECONDARY | 8.0.28 | XCom |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE | SECONDARY | 8.0.28 | XCom |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
すべてのメンバーのMEMBER_STATE値はONLINEである必要があります。新しいグループの場合、数秒以上RECOVERINGとしてリストされているノードがある場合、通常はエラーが発生したか、何かが誤って構成されていることを示しています。 追加情報を取得するには、/var/log/mysql/error.logでログを確認してください。
次に、テストデータベース情報が新しいメンバーにレプリケートされているかどうかを確認します：
Output+----+-------+-------+-------+
| id | type | quant | color |
+----+-------+-------+-------+
| 1 | slide | 2 | blue |
+----+-------+-------+-------+
1 row in set (0.01 sec)
データが新しいメンバーに利用可能であれば、グループレプリケーションが正常に機能していることを意味します。
ステップ6 — 新しいグループメンバーの書き込み機能のテスト
次に、新しいレプリケーショングループメンバーからデータベースに書き込んでみることができます。 これが成功するかどうかは、単一のプライマリまたはマルチプライマリグループを構成するかどうかに依存します。
単一プライマリ環境での書き込みのテスト
単一のプライマリグループでは、一貫性の理由から、非プライマリサーバーからのすべての書き込み操作が拒否されることが予想されます。常にレプリケーショングループのいずれかのメンバーで次のクエリを実行することで、現在のプライマリを見つけることができます：
Output+----------------------------------+--------------------------------------+
| Variable_name | Value |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)
クエリの値は、以前と同様にグループメンバーリストをクエリしてホストに一致させることができるMEMBER_IDです：
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)
この例の出力が示すように、203.0.113.1のホスト — メンバー1 — が現在プライマリサーバーです。別のメンバーからデータベースに書き込みを試みると、操作は失敗します：
OutputERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
これは、グループが現在単一の書き込み可能なプライマリで構成されているため、予想される動作です。プライマリサーバーに問題が発生してグループから脱退した場合、グループは自動的に新しいメンバーをプライマリとして選出し、書き込みを受け付けます。
マルチプライマリ環境での書き込みのテスト
マルチプライマリ方向に構成されたグループでは、どのメンバーでもデータベースに書き込みをコミットできるはずです。
グループがマルチプライマリモードで動作しているかどうかを再度group_replication_primary_member変数の値をチェックして、確認できます。
Output+----------------------------------+-------+
| Variable_name | Value |
+----------------------------------+-------+
| group_replication_primary_member | |
+----------------------------------+-------+
1 row in set (0.02 sec)
変数が空の場合、指定されたプライマリホストがないことを意味し、どのメンバーでも書き込みを受け入れることができるはずです。
これをmember2で、equipmentテーブルにデータを書き込むことを試みることでテストしてください。
OutputQuery OK, 1 row affected (0.00 sec)
member2は、エラーなしで書き込み操作をコミットしました。
member3で、新しいアイテムが追加されたかどうかを確認するために、次のクエリを実行してください。
Output+----+-------+-------+--------+
| id | type | quant | color |
+----+-------+-------+--------+
| 1 | slide | 2 | blue |
| 2 | swing | 10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)
これにより、member2の書き込みが正常にレプリケートされたことが確認されます。
次に、member3で書き込み機能をテストするために、次のINSERTステートメントを実行してください。
OutputQuery OK, 1 row affected (0.02 sec)
member1に戻り、新しいメンバーの両方からの書き込み操作がレプリケートされたことを確認するためにテストしてください。
Output+----+--------+-------+--------+
| id | type | quant | color |
+----+--------+-------+--------+
| 1 | slide | 2 | blue |
| 2 | swing | 10 | yellow |
| 3 | seesaw | 3 | green |
+----+--------+-------+--------+
3 rows in set (0.01 sec)
これにより、レプリケーションが各方向で機能し、各メンバーが書き込み操作を実行できることが確認されます。
ステップ7 — グループの再起動
一度グループがブートストラップされると、個々のメンバーは、プライマリサーバーを選出するのに十分なメンバーがいる限り、参加および退出しても可用性に影響しません。ただし、特定の構成変更（単一プライマリ環境とマルチプライマリ環境の切り替えなど）が行われた場合や、グループのすべてのメンバーが退出した場合は、初期設定と同じ方法でグループを再ブートストラップする必要があります。
メンバー1で、group_replication_bootstrap_group変数をONに設定します：
次に、グループを初期化します：
その後、group_replication_bootstrap_group変数をOFFに戻すことができます：
最初のメンバーがグループを開始した後、他のメンバーが参加できます：
その後、追加のメンバーに対してもこのプロセスを繰り返します：
グループは今、すべてのメンバーが利用可能な状態でオンラインになっているはずです：
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)
このプロセスは必要に応じてグループを再度開始するために使用できます。
ステップ8 — MySQLの起動時に自動的にグループに参加する
現在の設定では、メンバーサーバーが再起動しても、起動時に自動的にグループに再参加しません。メンバーが自動的にグループに再参加するようにしたい場合は、設定ファイルをわずかに変更できます。
次のステップで概説されている設定は、メンバーが起動すると自動的に参加する場合に役立ちます。 ただし、いくつかの注意点があります。まず、この設定は、MySQLインスタンス自体が開始されるときにのみ影響します。メンバーがタイムアウトの問題でグループから削除された場合でも、MySQLインスタンスがオンラインのままであれば、メンバーは自動的に再参加しません。
第二に、この設定を最初にグループを起動するときに有効にしておくと、有害です。既存のグループに参加するための既存のグループがない場合、MySQLプロセスは他の存在しないメンバーに接続しようとして初期化するために長時間かかります。長いタイムアウト後、通常どおりに開始されます。その後、上記の手順を使用してグループを起動する必要があります。
上記の注意点を考慮して、MySQLの起動時にノードをグループに自動的に参加させる場合は、メインのMySQL設定ファイルを開きます：
内部で、loose-group_replication_start_on_boot変数を検索し、ONに設定します：
[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .
作業が完了したら、ファイルを保存して閉じます。次回、MySQLインスタンスが起動すると、メンバーは自動的にグループに参加しようとします。
結論
このチュートリアルを完了することで、3つのUbuntu 20.04サーバー間でMySQLグループレプリケーションを構成する方法を学びました。単一プライマリの設定では、メンバーは必要に応じて書き込み可能なプライマリを自動的に選出します。マルチプライマリグループの場合、どのメンバーでも書き込みや更新を行うことができます。
グループレプリケーションは、メンバーが自由に参加または離脱できる柔軟なレプリケーショントポロジーを提供しつつ、データの一貫性とメッセージの順序に関する保証を同時に提供します。MySQLグループレプリケーションは、従来のレプリケーションでは不可能な機能を提供するため、少し複雑な構成になるかもしれません。