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