このページは機械翻訳したものです。

17.4.9 非同期接続フェイルオーバーによるソースの切替え

MySQL 8.0.22 以降では、レプリカからソースへの既存の接続が失敗した後、非同期接続フェイルオーバーメカニズムを使用して、新しいソースへの非同期 (ソースからレプリカ) レプリケーション接続を自動的に確立できます。 非同期接続フェイルオーバーメカニズムを使用すると、データを共有する複数の MySQL サーバーまたはサーバーグループとのレプリカの同期を維持できます。 潜在的なソースサーバーのリストはレプリカに格納され、接続障害が発生すると、設定した重み付け優先度に基づいて新しいソースがリストから選択されます。

MySQL 8.0.23 から、非同期接続フェイルオーバーメカニズムでは、グループメンバーシップに対する変更を自動的に監視し、プライマリサーバーとセカンダリサーバーを区別することで、グループレプリケーショントポロジもサポートされます。 グループメンバーをソースリストに追加し、それを管理対象グループの一部として定義すると、非同期接続フェイルオーバーメカニズムによってソースリストが更新され、メンバーシップの変更にあわせて保持され、グループメンバーの追加または削除が自動的に行われます。 接続およびステータスの取得に使用されるのは、大多数のオンライングループメンバーのみです。 管理対象グループの最後に残っているメンバーは、グループから移動しても自動的に削除されないため、管理対象グループの構成は保持されますが、管理対象グループが不要になった場合は手動で削除できます。

レプリケーションチャネルの非同期接続フェイルオーバーをアクティブ化するには、チャネルの CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) で SOURCE_CONNECTION_AUTO_FAILOVER=1 を設定します。 GTID 自動配置は、チャネルで使用されている必要があります (SOURCE_AUTO_POSITION = 1 | MASTER_AUTO_POSITION = 1)。 このオプションは、レプリカの実行中に設定できます。

重要

ソースへの既存の接続に失敗した場合、レプリカはまず、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの SOURCE_RETRY_COUNT | MASTER_RETRY_COUNT オプションで指定された回数だけ同じ接続を再試行します。 試行間隔は、SOURCE_CONNECT_RETRY | MASTER_CONNECT_RETRY オプションによって設定されます。 これらの試行を使い果たすと、非同期接続フェイルオーバーメカニズムが引き継ぎます。 単一ソースへの接続用に設計されたこれらのオプションのデフォルトでは、レプリカは 60 日間同じ接続を再試行します。 非同期接続フェイルオーバーメカニズムをすぐにアクティブ化できるようにするには、接続障害の原因が一時的なネットワーク停止である場合に備えて、SOURCE_RETRY_COUNT | MASTER_RETRY_COUNT および SOURCE_CONNECT_RETRY | MASTER_CONNECT_RETRY を、同じソースでの再試行を数回のみ許可する最小数に設定します。 適切な値は、SOURCE_RETRY_COUNT=3 | MASTER_RETRY_COUNT=3 と SOURCE_CONNECT_RETRY=10 | MASTER_CONNECT_RETRY=10 です。これにより、レプリカは 10 秒間隔で接続を 3 回再試行します。

また、レプリケーションチャネルのレプリカにソースリストを設定します。 asynchronous_connection_failover_add_source および asynchronous_connection_failover_delete_source UDF を使用してソースリストを設定および管理し、単一のレプリケーションサーバーを追加および削除します。 サーバーの管理対象グループを追加および削除するには、かわりに asynchronous_connection_failover_add_managed および asynchronous_connection_failover_delete_managed UDF を使用します。

UDF は、関連するレプリケーションチャネルに名前を付け、チャネルソースリストに対して追加または削除する MySQL インスタンスのホスト名、ポート番号、ネットワークネームスペースおよび重み付け優先度 (1-100、100 が最高の優先度) を指定します。 管理対象グループの場合は、管理対象サービスのタイプ (現在使用可能なのは Group Replication のみ) および管理対象グループの識別子 (Group Replication の場合は group_replication_group_name システム変数の値) も指定します。 管理対象グループを追加する場合、追加する必要があるのは 1 つのグループメンバーのみで、レプリカは現在のグループメンバーシップから残りを自動的に追加します。 管理対象グループを削除すると、グループ全体がまとめて削除されます。

MySQL 8.0.22 では、ソースへのレプリカ接続の失敗後に非同期接続フェイルオーバーメカニズムがアクティブ化され、START REPLICA | SLAVE ステートメントが発行されて新しいソースへの接続が試行されます。 このリリースでは、ソースの停止またはネットワーク障害が原因でレプリケーション I/O スレッドが停止した場合、接続はフェイルオーバーします。 レプリケーションスレッドが STOP REPLICA | SLAVE ステートメントによって停止された場合など、他の状況では接続はフェイルオーバーされません。

MySQL 8.0.23 では、ソースリストで使用可能な別のサーバーの優先度 (重み) 設定が高い場合、非同期接続フェイルオーバーメカニズムによって接続もフェイルオーバーされます。 この機能により、レプリカは常に最適なソースサーバーに接続されたままになり、管理対象グループと単一 (非管理対象) サーバーの両方に適用されます。 管理対象グループの場合、ソースの重みは、プライマリサーバーとセカンダリサーバーのどちらであるかによって割り当てられます。 したがって、プライマリに高い重みを与え、セカンダリに低い重みを与えるように管理対象グループを設定した場合、プライマリが変更されると、新しいプライマリに高い重みが割り当てられるため、レプリカは接続を介して変更されます。 非同期接続フェイルオーバーメカニズムでは、現在接続している管理対象ソースサーバーが管理対象グループから離れるか、管理対象グループの大部分に存在しなくなった場合にも、接続が変更されます。

接続をフェイルオーバーする場合、チャネルのソースリストにリストされている代替ソースの中で、優先度 (重み) が最も高いソースが最初の接続試行に対して選択されます。 レプリカは、まずソースサーバーに接続できることを確認します。管理対象グループの場合は、ソースサーバーがグループ内で ONLINE ステータスになっていることを確認します。 最も重み付けされたソースが使用できない場合、レプリカは、リストされたすべてのソースを重みの降順で試行し、最も重み付けされたソースから再開します。 複数のソースの重みが同じ場合、レプリカはそれらをランダムに順序付けします。 レプリカは、リストの操作を再度開始する必要がある場合、元の接続障害が発生したソースを含めて再試行します。

ソースリストは mysql.replication_asynchronous_connection_failover および mysql.replication_asynchronous_connection_failover_managed テーブルに格納され、「パフォーマンススキーマ」テーブル replication_asynchronous_connection_failover で表示できます。 レプリカは、モニタースレッドを使用して管理対象グループのメンバーシップを追跡し、ソースリスト (thread/sql/replica_monitor) を更新します。 CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの SOURCE_CONNECTION_AUTO_FAILOVER オプションの設定およびソースリストは、リモートクローニング操作中にレプリカのクローンに転送されます。

非同期接続フェイルオーバーメカニズムを使用するための要件は次のとおりです:

• GTID がソースおよびレプリカ (gtid_mode=ON) で使用されている必要があり、GTID 自動配置がソースへの接続に使用されるように、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの SOURCE_AUTO_POSITION | MASTER_AUTO_POSITION オプションがレプリカで有効になっている必要があります。

• チャネルのソースリスト内のすべてのソースサーバーに、同じレプリケーションユーザーアカウントおよびパスワードが存在する必要があります。 このアカウントは、各ソースへの接続に使用されます。 チャネルごとに異なるアカウントを設定できます。

• レプリケーションユーザーアカウントには、たとえば GRANT SELECT ON performance_schema.* TO 'repl_user';を発行して、「パフォーマンススキーマ」テーブルに対する SELECT 権限が付与されている必要があります

• レプリケーションユーザーアカウントおよびパスワードは、代替ソースへの接続のために自動再起動時に使用可能である必要があるため、レプリケーションの開始に使用するステートメントには指定できません。 これらは、レプリカで CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用してチャネルに設定し、レプリケーションメタデータリポジトリに記録する必要があります。