フレキシブル サーバー Azure Database for MySQL使用すると、自動フェールオーバーを使用して高可用性を構成できます。 このソリューションにより、障害が発生してもコミット済みのデータが失われることはなく、データベースがソフトウェア アーキテクチャ上の単一障害点になることもありません。 高可用性を構成すると、フレキシブル サーバーはスタンバイ レプリカを自動的にプロビジョニングおよび管理します。 プロビジョニングされたコンピューティングとストレージの両方に対して、プライマリ レプリカとセカンダリ レプリカによる料金が発生します。 高可用性のアーキテクチャ モデルには、2 種類の選択肢があります。
ゾーン冗長の高可用性。 このオプションにより、複数のAvailability Zonesにわたるインフラストラクチャの完全な分離と冗長性が提供されます。 このオプションは最高レベルの可用性を提供しますが、ゾーン間でアプリケーションの冗長性を構成する必要があります。 可用性ゾーン内のインフラストラクチャ障害から保護する場合、および可用性ゾーン全体の待機時間が許容される場合は、ゾーン冗長高可用性を選択します。 ゾーン冗長高可用性を有効にできるのは、サーバーを作成する場合のみです。 ゾーン冗長高可用性は、Azure リージョンのsubsetで利用できます。このリージョンでは複数のAvailability Zonesとゾーン冗長 Premium ファイル共有をサポートしています。
ローカル冗長の高可用性。 このオプションでは、プライマリ サーバーとスタンバイ サーバーが同じ可用性ゾーン内に配置されるため、インフラストラクチャの冗長性を確保しつつ、ネットワーク レイテンシを低く抑えることができます。 ゾーン間でアプリケーションの冗長性を構成する必要なく、高可用性を実現します。 ネットワーク待機時間が最も短い単一の可用性ゾーン内で最高レベルの可用性を実現する場合は、ローカル冗長高可用性を選択します。 ローカル冗長の高可用性は、Azure Database for MySQL フレキシブル サーバーを使用できるすべての Azure リージョン で利用可能です。
ゾーン冗長型高可用性 (HA) アーキテクチャ
ゾーン冗長の高可用性を備えたサーバーを展開すると、Azureは次の 2 つのサーバーを作成します。
- 1 つの可用性ゾーン内のプライマリ サーバー。
- 同じAzure リージョンの別の可用性ゾーンにあるスタンバイ レプリカ サーバー。 スタンバイ レプリカ サーバーには、コンピューティング レベル、コンピューティング サイズ、storage サイズ、ネットワーク構成など、プライマリ サーバーと同じ構成があります。
プライマリ サーバーとスタンバイ レプリカの両方について、可用性ゾーンを選択することができます。 スタンバイ データベース サーバーとスタンバイ アプリケーションを同じゾーンに配置すると、待機時間が短縮されます。 また、ディザスター リカバリーの状況やゾーンダウンシナリオに備えるのにも役立ちます。
ローカル冗長高可用性のアーキテクチャを示す図。
データ ファイルとログ ファイルは、ゾーン冗長型ストレージ (ZRS) でホストされています。 スタンバイ サーバーは、プライマリ サーバーのstorage アカウントからログ ファイルを継続的に読み取って再生します。このアカウントは、storage レベルのレプリケーションによって保護されます。
フェールオーバーが発生した場合:
- スタンバイ レプリカが起動します。
- プライマリ サーバーのバイナリ ログ ファイルはスタンバイ サーバーに継続的に適用され、プライマリ サーバー上の最後にコミットされたトランザクションまでオンライン状態に復元されます。
ZRS のログには、プライマリ サーバーが使用できない場合でもアクセスできます。 この可用性により、データが失われないことが保証されます。 スタンバイ レプリカが起動し、バイナリ ログが適用された後、現在のスタンバイ レプリカ サーバーがプライマリ サーバーの役割を引き継ぎます。 クライアントが再接続されたときにクライアント接続が新しいプライマリに直接接続されるように、DNS が更新されます。 フェールオーバーは、クライアント アプリケーションから完全に透過的で、ユーザーによる操作は必要ありません。 その後、HA ソリューションによって、可能であれば古いプライマリ サーバーが回復され、スタンバイとして配置されます。
アプリケーションをプライマリ サーバーに接続するには、データベース サーバー名を使用します。 このソリューションでは、スタンバイ レプリカ情報は直接アクセス用に公開されません。 プライマリ サーバーの ZRS でログ ファイルがフラッシュされた後で、コミットと書き込みが認められます。 ZRS storageで使用される同期レプリケーション テクノロジにより、アプリケーションの書き込みとコミットの待機時間が 5 ~ 10% 増加する可能性があります。
プライマリ データベース サーバーは、ゾーン冗長storageのスナップショットとログ バックアップの両方を自動的にバックアップします。
ローカル冗長高可用性 (HA) アーキテクチャ
ローカル冗長 HA を使用してサーバーをデプロイする場合は、同じゾーンに 2 つのサーバーを作成します。
- プライマリ サーバー
- プライマリ サーバーと同じ構成を持つスタンバイ レプリカ サーバー (コンピューティング レベル、コンピューティング サイズ、storage サイズ、ネットワーク構成)
スタンバイ サーバーは、個別の仮想マシン (コンピューティング) を使用してインフラストラクチャの冗長性を提供します。 この冗長性では、コロケーションのため、フェールオーバーの時間と、アプリケーションとデータベース サーバーの間のネットワーク待機時間が短縮されます。
ローカル冗長高可用性のアーキテクチャを示す図。
データ ファイルとログ ファイルは、ローカル冗長storage (LRS) でホストされます。 スタンバイ サーバーは、プライマリ サーバーのstorage アカウントからログ ファイルを継続的に読み取って再生します。これは、storage レベルのレプリケーションによって保護されます。
フェールオーバーが発生した場合:
- スタンバイ レプリカが起動します。
- プライマリ サーバーのバイナリ ログ ファイルはスタンバイ サーバーに継続的に適用され、プライマリ サーバー上の最後にコミットされたトランザクションまでオンライン状態に復元されます。
LRS のログには、プライマリ サーバーが使用できない場合でもアクセスできます。 この可用性により、データが失われないことが保証されます。 スタンバイ レプリカがアクティブ化され、バイナリ ログが適用されると、現在のスタンバイ レプリカがプライマリ サーバーの役割を担います。 クライアントの再接続時に、接続が新しいプライマリにリダイレクトされるように、DNS が更新されます。 フェールオーバーは、クライアント アプリケーションから完全に透過的で、ユーザーによる操作は必要ありません。 その後、HA ソリューションによって、可能であれば古いプライマリ サーバーが回復され、スタンバイとして配置されます。
データベース サーバー名を使用して、アプリケーションはプライマリ サーバーに接続されます。 スタンバイレプリカの情報は、直接アクセスでは公開されません。 プライマリ サーバーの LRS でログ ファイルがフラッシュされた後で、コミットと書き込みが認められます。 プライマリとスタンバイ レプリカが同じゾーン内にあるため、アプリケーション サーバーとデータベース サーバーの間のレプリケーションの遅延が小さくなり、待機時間が短くなります。 ローカル冗長セットアップでは、依存インフラストラクチャが特定の可用性ゾーンに対してダウンしている場合、高可用性は提供されません。 その可用性ゾーンに関連するすべての依存サービスが復旧するまで、ダウンタイムが発生します。
プライマリ データベース サーバーは、スナップショットとログ バックアップの両方をローカル冗長storageに自動的にバックアップします。
注
ゾーン冗長 HA とローカル冗長 HA の両方の場合:
- 障害が発生した場合、スタンバイ レプリカがプライマリの役割を引き継ぐのに必要な時間は、プライマリ storage アカウントからスタンバイへのバイナリ ログの再生にかかる時間によって異なります。 フェールオーバー時間を短縮するには、すべてのテーブルに主キーを設定してください。 フェールオーバーには通常 60 から 120 秒程度かかります。
- スタンバイ サーバーは、読み取りまたは書き込み操作には使用できません。 高速フェールオーバーを可能にするためのパッシブ スタンバイです。
- プライマリ サーバーへの接続には、常に完全修飾ドメイン名 (FQDN) を使用します。 接続に IP アドレスを使用しないようにします。 フェールオーバーが発生し、プライマリ サーバーとスタンバイ サーバーの役割が切り替わった後、DNS の A レコードが変更される可能性があります。 この変更により、接続文字列で IP アドレスが使用されている場合、アプリケーションは新しいプライマリ サーバーに接続できなくなります。
フェールオーバー プロセス
Azure Database for MySQLのフェールオーバー プロセス中に、システムは自動的にプライマリ サーバーからスタンバイ レプリカに切り替えます。 この切り替えにより、サービスの継続性が確保され、ダウンタイムが最小限に抑えられます。 システムが障害を検出すると、スタンバイ レプリカが昇格され、新しいプライマリ サーバーになります。 システムは、元のプライマリ サーバーのバイナリ ログ ファイルをスタンバイ レプリカに適用します。 この処理により、スタンバイ レプリカは最後にコミットされたトランザクションまで同期され、データ損失が発生しないように保証されます。 このシームレスな移行は、データベース サービスの高可用性と信頼性を維持するのに役立ちます。
注
2025 年 10 月以降、パブリック accessまたはPrivate Linkで作成されたすべての新しい高可用性サーバーでは、DNS キャッシュへのフェールオーバー時間の依存関係を短縮するために、高可用性サーバーごとに専用の SLB を備えた新しいアーキテクチャが採用されています。 MySQL データ トラフィック パスを管理することで、SLB はフェールオーバー中の DNS 変更の必要性を排除し、フェールオーバーのパフォーマンスを大幅に向上させます。 負荷分散規則を使用して、フェールオーバー中にトラフィックを現在のプライマリ インスタンスにリダイレクトします。 パブリックアクセスまたはプライベートリンクを持つ既存のサーバーは、影響を最小限に抑えるために段階的に移行しています。 早期移行を希望するお客様は、高可用性を無効にして再度有効にすることができます。 この機能は、VNet 統合でプライベート accessを使用するサーバーではサポートされていません。
計画的: 強制フェールオーバー
フレキシブル サーバー Azure Database for MySQL強制フェールオーバーを使用すると、手動でフェールオーバーを強制できます。 この機能により、アプリケーションのシナリオに沿った動作確認が可能となり、障害への備えにも役立ちます。
強制フェールオーバーは、同じデータベース サーバー名を使用して DNS レコードを更新することで、スタンバイ レプリカをアクティブ化してプライマリ サーバーになるフェールオーバーをトリガーします。 元のプライマリ サーバーが再起動し、スタンバイ レプリカに切り替わります。 クライアント接続は切断され、処理を再開するには再接続が必要となります。
フェールオーバー全体の時間は、現在のワークロードと最後のチェックポイントによって異なります。 一般に、フェイル オーバーにかかる時間は 60 秒から 120 秒です。
注
Azure Resource Health イベントは、計画されたフェールオーバー中に生成されます。 このイベントは、サーバーが利用できないフェールオーバー期間を示します。 左側のウィンドウの Resource Health で選択すると、トリガーされたイベントを確認できます。 状態は、ユーザーが開始したフェールオーバーまたは手動フェールオーバーを [利用不可] として表し、[計画済み] としてタグ付け されます。 たとえば、 フェールオーバー操作は、承認されたユーザー (計画済み) によってトリガーされました。 リソースが長期間この状態のままである場合は、support チケットを開き、お手伝いします。
計画外: 自動フェールオーバー
計画外のサービスのダウンタイムは、ソフトウェアのバグやインフラストラクチャの障害 (コンピューティング、ネットワーク、storageの障害など) が原因で発生する可能性があります。 停電もデータベースの可用性に影響を及ぼす可能性があります。 データベースが利用不可になると、スタンバイ レプリカへのレプリケーションが停止し、スタンバイ レプリカがプライマリ データベースに昇格します。 DNS が更新されると、クライアントはデータベース サーバーに再接続し、処理を再開します。
フェールオーバー全体の所要時間は、通常 60 から 120 秒程度です。 ただし、フェールオーバー時のプライマリ データベース サーバーの処理状況 (大規模なトランザクションや復旧時間など) によっては、フェールオーバーにより長い時間がかかる場合があります。
注
Azure Resource Health イベントは、計画外のフェールオーバー中に生成されます。 このイベントは、サーバーが利用できないフェールオーバー期間を示します。 左側のウィンドウで Resource Health を選択すると、トリガーされたイベントを確認できます。 自動フェールオーバーでは、状態が [利用不可] と表示され、[計画外] とタグ付 けされます。
たとえば、 使用不可: フェールオーバー操作が自動的にトリガーされました (計画外)。 リソースが長時間この状態にある場合は、サポートチケットを開いてください。そうすれば、こちらでサポートいたします。
HA が有効になっているサーバーでの自動フェールオーバー検出のしくみ
プライマリ サーバーとセカンダリ サーバーには、それぞれ 2 つのネットワーク エンドポイントがあります。
- 顧客エンドポイント: このエンドポイントを使用して、顧客はインスタンスに接続し、クエリを実行します。
- 管理エンドポイント: 管理コンポーネントへのサービス通信とバックエンド storageへの接続に内部的に使用されます。
正常性モニター コンポーネントにより、次のチェックが絶えず実行されます。
- モニターはノードの管理ネットワーク エンドポイントに ping を送信します。 このチェックが連続して 2 回失敗すると、自動フェールオーバー操作がトリガーされます。 この正常性チェックは、OS の問題、管理コンポーネントとノード間のネットワークの問題、および同様の問題によるノードの使用不能または非応答などのシナリオに対処します。
- モニターはインスタンス上で簡単なクエリを実行します。 クエリの実行に失敗すると、自動フェールオーバーがトリガーされます。 この正常性チェックは、MySQL デーモンのクラッシュ、停止、ハング、バックエンドstorageの問題や同様の問題などのシナリオに対処します。
注
正常性チェックでは、アプリケーションと顧客のネットワーク エンドポイント (プライベート/パブリック access) の間のネットワークの問題は監視されません。 これらの問題は、ネットワーク パス、エンドポイント、またはクライアント側の DNS の問題で発生する可能性があります。 プライベート accessを使用する場合は、Virtual Networkの NSG 規則によって、ポート 3306 のインスタンス顧客ネットワーク エンドポイントへの通信がブロックされていないことを確認します。 パブリック accessの場合は、ファイアウォール規則が設定され、ネットワーク トラフィックがポート 3306 で許可されていることを確認します (ネットワーク パスに他のファイアウォールがある場合)。 クライアント アプリケーション側での DNS 解決にも注意が必要です。
高可用性を監視する
サーバーの高可用性構成の状態を確認するには、ポータルのサーバーの [高可用性] ペインにある [高可用性の状態] を使用してください。
| 地位 | 説明 |
|---|---|
| NotEnabled | 高可用性が有効ではありません。 |
| ReplicatingData | スタンバイ サーバーは、高可用性サーバーのプロビジョニング中、または高可用性オプションを有効にすると、プライマリ サーバーと同期します。 |
| FailingOver | データベース サーバーがプライマリからスタンバイへフェールオーバー中です。 |
| Healthy | 高可用性オプションが有効になっています。 |
| RemovingStandby | 高可用性オプションを無効にすると、削除プロセスが進行中です。 |
高可用性サーバーの正常性を監視するには、次のメトリックを使用します。
| メトリックの表示名 | メトリック | 単位 | 説明 |
|---|---|---|---|
| HA の状態 | ha_io_running | 状態 | HA 状態は、HA レプリケーションの状態を示します。 I/O スレッドが実行中の場合、メトリックの値は 1 になり、そうでない場合は 0 になります。 |
| HA SQL の状態 | ha_sql_running | 状態 | HA SQL の状態は、高可用性レプリケーションの状態を示します。 SQL スレッドが実行中の場合、メトリックの値は 1 になり、そうでない場合は 0 になります。 |
| HA レプリケーションのラグ | レプリケーション遅延 | 秒 | レプリケーションのラグは、プライマリ サーバーで受信したトランザクションをスタンバイが再生する際の遅延秒数です。 |
制限事項
高可用性を使用する場合は、次の考慮事項に注意してください。
ゾーン冗長高可用性は、サーバーの作成時にのみ構成できます。
バースト可能なコンピューティング レベルでは、高可用性はサポートされていません。
静的パラメーターの変更を適用するためにプライマリ データベース サーバーを再起動すると、スタンバイ レプリカも再起動されます。
このソリューションでは GTID を使用しているため、GTID モードが有効になります。 お使いのワークロードに、GTID を使用したレプリケーションに関する制限があるかどうか確認してください。
注
Storage自動拡張は、高可用性構成サーバーに対して既定で有効になっており、無効にすることはできません。
既知の問題
Azure Database for MySQLフレキシブル サーバーでは、バックエンドでネイティブ MySQL レプリケーションが使用されます。 MySQL Community Edition 8.0 以降には、ON DELETE CASCADE を使用して外部キーの制約に依存する複数テーブル DELETE 操作を実行するときにレプリケーションを中断する可能性がある既知の問題が存在します。 この問題は、 MySQL バグ 102586として追跡されます。 その結果、Azure Database for MySQLフレキシブル サーバーで高可用性を有効にする場合は、外部キーで連鎖削除を使用しないようにします。このパターンはレプリケーションの失敗につながる可能性があり、サーバーの可用性に影響を与える可能性があるためです。
正常性のチェック
Azure Database for MySQLの高可用性 (HA) を構成する場合、正常性チェックはデータベースの信頼性とパフォーマンスを維持する上で重要な役割を果たします。 これらのチェックは、プライマリ レプリカとスタンバイ レプリカの両方の状態と正常性を継続的に監視し、問題を迅速に検出できるようにします。 サーバーの応答性、レプリケーションのラグ、リソースの使用率などのさまざまなメトリックを追跡する正常性チェックは、確実にフェールオーバー プロセスをシームレスに実行できるようにして、ダウンタイムを最小限に抑え、データ損失を防ぐのに役立ちます。 適切に構成された正常性チェックは、データベースのセットアップで必要なレベルの可用性と回復性を実現するために不可欠です。
正常性の監視
Azure portalを使用して、HA セットアップの正常性を監視できます。 監視する主なメトリックは次のとおりです。
- サーバーの応答性: プライマリ サーバーが到達可能であるかどうかを示します。
- レプリケーションのラグ: プライマリとスタンバイのレプリカ間の遅延を測定し、データの一貫性を保ちます。
- リソース使用率: CPU、メモリ、およびstorageの使用状況を監視してボトルネックを防ぎます。
関連コンテンツ
- 高可用性
- ビジネス継続性
- ゾーン冗長の高可用性
- バックアップと回復