このセクションでは、グループレプリケーションに使用する MySQL Server インスタンスに必要な構成設定について説明します。 背景情報については、セクション18.9「要件と制限事項」 を参照してください。
Group Replication の場合、データは InnoDB トランザクションストレージエンジンに格納される必要があります (理由の詳細は、セクション18.9.1「グループレプリケーションの要件」 を参照してください)。 一時的な MEMORY ストレージエンジンを含むほかのストレージエンジンを使用すると、Group Replication でエラーが発生する可能性があります。 disabled_storage_engines システム変数を次のように設定して、使用しないようにします:
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
MyISAM ストレージエンジンが無効になっている場合、mysql_upgrade がまだ使用されているリリース (MySQL 8.0.16 より前) に MySQL インスタンスをアップグレードすると、mysql_upgrade がエラーで失敗することがあります。 これを処理するには、mysql_upgrade の実行中にそのストレージエンジンを再度有効にし、サーバーの再起動時に再度無効にします。 詳細は、セクション4.4.5「mysql_upgrade — MySQL テーブルのチェックとアップグレード」を参照してください。
次の設定では、MySQL Group Replication の要件に従ってレプリケーションを構成します。
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ONこれらの設定は、一意の識別子番号 1 を使用して セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」 を有効にし、GTID を使用して安全にログに記録できるステートメントのみを実行できるようにサーバーを構成します。
MySQL 8.0.20 までは、次の設定も必要です:
binlog_checksum=NONEこの設定により、バイナリログに書き込まれたイベントのチェックサムが無効になり、デフォルトで有効になります。 MySQL 8.0.21 から、Group Replication はバイナリログ内のチェックサムの存在をサポートし、それらを使用して一部のチャネルでのイベントの整合性を検証できるため、デフォルト設定を使用できます。 詳細は、セクション18.9.2「グループレプリケーションの制限事項」を参照してください。
レプリケーションのデフォルトが改善された 8.0.3 より前のバージョンの MySQL を使用している場合は、これらの行をメンバーオプションファイルに追加する必要もあります。 以降のバージョンのオプションファイルにこれらのシステム変数が含まれている場合は、それらが次のように設定されていることを確認します。 詳細は、セクション18.9.1「グループレプリケーションの要件」 を参照してください。
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction_write_set_extraction=XXHASH64この時点で、オプションファイルによってサーバーが構成され、特定の構成でレプリケーションインフラストラクチャをインスタンス化するように指示されます。 次のセクションでは、サーバーのグループレプリケーション設定を構成します。
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s1:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group=offplugin-load-addは、起動時にサーバーがロードするプラグインのリストに Group Replication プラグインを追加します。 これは、プラグインを手動でインストールするよりも本番デプロイメントでお薦めします。-
group_replication_group_nameの構成は、参加または作成しているグループの名前が "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" であることをプラグインに伝えます。group_replication_group_nameの値は有効な UUID である必要があります。 この UUID は、バイナリログ内のグループレプリケーションイベントの GTID を設定するときに内部的に使用されます。SELECT UUID()を使用して UUID を生成できます。 offにgroup_replication_start_on_boot変数を構成すると、サーバーの起動時に自動的に操作を開始しないようにプラグインに指示されます。 これは、プラグインを手動で起動する前にサーバーを構成できるようにするため、Group Replication を設定する際に重要です。 メンバーを構成したら、サーバーの起動時にグループレプリケーションが自動的に開始されるように、group_replication_start_on_bootをonに設定できます。-
group_replication_local_addressを構成すると、メンバーがグループ内の他のメンバーとの内部通信に使用するネットワークアドレスとポートが設定されます。 グループレプリケーションは、グループ通信エンジン (XCom、Paxos バリアント) のリモートインスタンスを含む内部メンバーからメンバーへの接続にこのアドレスを使用します。重要グループレプリケーションのローカルアドレスは、MySQL Server
hostnameおよびportシステム変数で定義される SQL クライアント接続に使用されるホスト名およびポートとは異なる必要があります。 クライアントアプリケーションには使用しないでください。 グループレプリケーションの実行中にグループのメンバー間の内部通信にのみ使用する必要があります。group_replication_local_addressによって構成されたネットワークアドレスは、すべてのグループメンバーが解決できる必要があります。 たとえば、各サーバーインスタンスが固定ネットワークアドレスを持つ異なるマシン上にある場合、10.0.0.1 などのマシンの IP アドレスを使用できます。 ホスト名を使用する場合は、完全修飾名を使用し、DNS、正しく構成された/etc/hostsファイルまたはその他の名前解決プロセスを介して解決できることを確認する必要があります。 MySQL 8.0.14 からは、IPv6 アドレス (またはそれらに解決されるホスト名) と IPv4 アドレスを使用できます。 グループには、IPv6 を使用するメンバーと IPv4 を使用するメンバーを混在させることができます。 IPv6 ネットワークおよび IPv4 と IPv6 の混合グループに対するグループレプリケーションサポートの詳細は、セクション18.4.5「IPv6 および IPv6 と IPv4 の混合グループのサポート」 を参照してください。group_replication_local_addressの推奨ポートは 33061 です。group_replication_local_addressは、グループレプリケーションによって、レプリケーショングループ内のグループメンバーの一意の識別子として使用されます。 このチュートリアルで示すように、ホスト名または IP アドレスがすべて異なるかぎり、レプリケーショングループのすべてのメンバーに同じポートを使用できます。 または、セクション18.2.2「グループレプリケーションのローカルでのデプロイ」 に示すように、ポートがすべて異なるかぎり、すべてのメンバーに同じホスト名または IP アドレスを使用できます。グループレプリケーション分散リカバリプロセスで既存のメンバーが参加メンバーに提供する接続は、
group_replication_local_addressによって構成されたネットワークアドレスではありません。 MySQL 8.0.20 まで、グループメンバーは、MySQL Serverhostnameおよびportシステム変数で指定されている分散リカバリのためにメンバーを結合するための標準 SQL クライアント接続を提供します。 MySQL 8.0.21 から、グループメンバーは分散リカバリエンドポイントの代替リストをメンバー参加専用のクライアント接続として通知できます。 詳細は、セクション18.4.3.1「分散リカバリの接続」を参照してください。重要結合メンバーが、MySQL Server
hostnameシステム変数で定義されたホスト名を使用して他のメンバーを正しく識別できない場合、分散リカバリは失敗する可能性があります。 MySQL を実行しているオペレーティングシステムでは、DNS またはローカル設定を使用して、一意のホスト名を適切に構成することをお薦めします。 サーバーが SQL クライアント接続に使用しているホスト名は、「パフォーマンススキーマ」テーブルreplication_group_membersのMember_hostカラムで確認できます。 複数のグループメンバーがオペレーティングシステムによって設定されたデフォルトのホスト名を外部化する場合、参加メンバーが正しいメンバーアドレスに解決せず、分散リカバリのために接続できない可能性があります。 この状況では、MySQL Serverreport_hostシステム変数を使用して、各サーバーによって外部化される一意のホスト名を構成できます。 -
group_replication_group_seedsを構成すると、新しいメンバーがグループへの接続を確立するために使用するグループメンバーのホスト名とポートが設定されます。 これらのメンバーはシードメンバーと呼ばれます。 接続が確立されると、グループメンバーシップ情報が「パフォーマンススキーマ」テーブルreplication_group_membersにリストされます。 通常、group_replication_group_seedsリストには各グループメンバーgroup_replication_local_addressのhostname:portが含まれますが、これは義務ではなく、グループメンバーのサブセットをシードとして選択できます。重要group_replication_group_seedsにリストされているhostname:portは、group_replication_local_addressによって構成されたシードメンバーの内部ネットワークアドレスであり、「パフォーマンススキーマ」テーブルreplication_group_membersなどに示されている SQL クライアント接続に使用されるhostname:portではありません。グループを起動するサーバーは、このオプションを使用しません。これは、このオプションが初期サーバーであり、グループのブートストラップを担当しているためです。 つまり、グループをブートストラップするサーバー上の既存のデータは、次の結合メンバーのデータとして使用されます。 2 つ目のサーバーを結合すると、グループ内の 1 つのメンバーと唯一のメンバーに参加するように要求され、2 つ目のサーバー上の欠落しているデータはブートストラップメンバー上のドナーデータからレプリケートされ、グループが展開されます。 3 つ目のサーバー結合では、これらの 2 つのいずれかを結合するように要求できます。データは新しいメンバーに同期され、グループが再度展開されます。 後続のサーバーは、参加時にこの手順を繰り返します。
警告複数のサーバーに同時に参加する場合は、グループにすでに存在するシードメンバーを指していることを確認してください。 グループに参加しているメンバーは、連絡時にまだグループに属していない可能性があるため、シードとして使用しないでください。
ブートストラップメンバーを最初に起動し、グループを作成することをお薦めします。 次に、参加している残りのメンバーのシードメンバーにします。 これにより、残りのメンバーを結合するときにグループが形成されます。
グループの作成と複数のメンバーの同時参加はサポートされていません。 これは機能する可能性がありますが、操作が競合してから、グループに参加する操作がエラーまたはタイムアウトで終了する可能性があります。
参加メンバーは、シードメンバーが
group_replication_group_seedsオプションで通知するプロトコル (IPv4 または IPv6) と同じプロトコルを使用してシードメンバーと通信する必要があります。 グループレプリケーションの IP アドレス権限のために、シードメンバーの許可リストには、シードメンバーが提供するプロトコルの参加メンバーの IP アドレス、またはそのプロトコルのアドレスに解決されるホスト名が含まれている必要があります。 このアドレスのプロトコルがシードメンバーに通知されたプロトコルと一致しない場合は、参加メンバーgroup_replication_local_addressに加えて、このアドレスまたはホスト名を設定して許可する必要があります。 参加メンバーに適切なプロトコルの許可されたアドレスがない場合、その接続試行は拒否されます。 詳細は、セクション18.5.1「グループレプリケーション IP アドレスの権限」を参照してください。 -
group_replication_bootstrap_groupを構成すると、グループをブートストラップするかどうかをプラグインに指示します。 この場合、s1 がグループの最初のメンバーであっても、オプションファイルでこの変数を off に設定します。 かわりに、インスタンスの実行中にgroup_replication_bootstrap_groupを構成して、実際にグループをブートストラップするメンバーが 1 人のみであることを確認します。重要group_replication_bootstrap_group変数は、グループに属しているあるサーバーインスタンスでのみ有効にする必要があります。通常は、グループを初めてブートストラップするとき (または、グループ全体を停止して再度起動する場合) に有効にします。 グループを複数回ブートストラップする場合 (たとえば、複数のサーバーインスタンスにこのオプションが設定されている場合)、同じ名前の異なる 2 つのグループが存在する人工的な分割ブレーンシナリオを作成できます。 最初のサーバーインスタンスがオンラインになった後は、必ずgroup_replication_bootstrap_group=offを設定してください。
グループ内のすべてのサーバーの構成は非常に似ています。 各サーバー (server_id, datadir, group_replication_local_address など) の詳細を変更する必要があります。 これは、このチュートリアルの後半で説明します。