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)。 このオプションは、レプリカの実行中に設定できます。

また、レプリケーションチャネルのレプリカにソースリストを設定します。 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 オプションの設定およびソースリストは、リモートクローニング操作中にレプリカのクローンに転送されます。

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