Azure Database for MySQL フレキシブル サーバーでの高可用性の概念

  • [アーティクル]

適用対象: Azure Database for MySQL - フレキシブル サーバー

Azure Database for MySQL フレキシブル サーバーを使用すると、自動フェールオーバーによる高可用性を構成できます。 高可用性ソリューションは、コミットされたデータが障害によって失われないこと、データベースがソフトウェア アーキテクチャでの単一障害点にならないことを保証するように設計されています。 高可用性が構成されている場合、フレキシブル サーバーでは、スタンバイ レプリカが自動的にプロビジョニングされ、管理されます。 プライマリ レプリカとセカンダリ レプリカの両方について、プロビジョニングされたコンピューティングとストレージに対して請求されます。 高可用性アーキテクチャ モデルには、次の 2 つがあります。

  • ゾーン冗長 HA。 このオプションは、複数の可用性ゾーンにわたるインフラストラクチャの完全な分離と冗長性を実現する場合に適しています。 最高レベルの可用性が提供されますが、複数のゾーンにわたってアプリケーションの冗長性を構成する必要があります。 可用性ゾーン内のインフラストラクチャ障害に対して最高レベルの可用性を実現する必要があり、可用性ゾーン全体の待機時間を許容できる場合は、ゾーン冗長 HA が推奨されます。 サーバーを作成するときにのみ有効にすることができます。 ゾーン冗長 HA は、リージョンで複数の可用性ゾーンがサポートされていて、ゾーン冗長 Premium ファイル共有が利用可能な、Azure リージョンのサブセットで利用できます。

  • 同一ゾーン HA。 このオプションは、プライマリ サーバーとスタンバイ サーバーが同じ可用性ゾーンに存在するので、ネットワーク待機時間が短いインフラストラクチャの冗長性に適しています。 高可用性を実現するのに、ゾーンをまたいでアプリケーションの冗長性を構成する必要がありません。 単一の可用性ゾーン内で、ネットワーク待機時間が最も短い最高レベルの可用性を実現する必要がある場合は、同一ゾーン HA が推奨されます。 同一ゾーン HA は、Azure Database for MySQL - フレキシブル サーバーを使用できるすべての Azure リージョンで使用できます。

ゾーン冗長 HA のアーキテクチャ

ゾーン冗長 HA を使用してサーバーをデプロイすると、2 つのサーバーが作成されます。

  • 1 つの可用性ゾーン内のプライマリ サーバー。
  • 同じ Azure リージョンの別の可用性ゾーン内に、プライマリ サーバーと同じ構成 (コンピューティング レベル、コンピューティング サイズ、ストレージ サイズ、ネットワーク構成) のスタンバイ レプリカ サーバー。

プライマリとスタンバイのレプリカの可用性ゾーンは選択できます。 スタンバイ データベース サーバーとスタンバイ アプリケーションを同じゾーンに配置すると、待機時間が短縮されます。 また、ディザスター リカバリー状況や "ゾーン ダウン" のシナリオに対して、より適切に備えることもできます。

ゾーン冗長高可用性のアーキテクチャを示す図。

データ ファイルとログ ファイルは、ゾーン冗長ストレージ (ZRS) でホストされます。 スタンバイ サーバーは、プライマリ サーバーのストレージ アカウントからログ ファイルを継続的に読み取って再生します。これは、ストレージ レベルのレプリケーションによって保護されます。

フェールオーバーが発生した場合:

  • スタンバイ レプリカがアクティブにされます。
  • プライマリ サーバーのバイナリ ログ ファイルが、スタンバイ サーバーに続けて適用され、プライマリで最後にコミットされたトランザクションまでオンラインになります。

ZRS のログには、プライマリ サーバーが使用できない場合でもアクセスできます。 この可用性により、データが失われないことが保証されます。 スタンバイ レプリカがアクティブにされて、バイナリ ログが適用された後は、現在のスタンバイ レプリカ サーバーがプライマリ サーバーの役割を引き継ぎます。 クライアントの再接続時に、クライアントの接続が新しいプライマリに転送されるように、DNS が更新されます。 フェールオーバーは、クライアント アプリケーションから完全に透過的で、ユーザーによる操作は必要ありません。 その後、HA ソリューションによって、可能であれば古いプライマリ サーバーが回復され、スタンバイとして配置されます。

プライマリ サーバーへのアプリケーションの接続には、データベース サーバー名が使用されます。 スタンバイ レプリカの情報が、直接アクセスのために公開されることはありません。 プライマリ サーバーの ZRS でログ ファイルがフラッシュされた後で、コミットと書き込みが認められます。 ZRS ストレージで使用される同期レプリケーション テクノロジのため、アプリケーションによる書き込みとコミットの待機時間が 5% から 10% 増加する場合があります。

スナップショットとログ バックアップ両方の自動バックアップは、ゾーン冗長ストレージ上でプライマリ データベース サーバーから実行されます。

同一ゾーン HA のアーキテクチャ

同じゾーン HA を使用してサーバーをデプロイすると、同じゾーンに 2 つのサーバーが作成されます。

  • プライマリ サーバー
  • プライマリ サーバーと同じ構成 (コンピューティング レベル、コンピューティング サイズ、ストレージ サイズ、ネットワーク構成) のスタンバイ レプリカ サーバー

スタンバイ サーバーにより、別の仮想マシン (コンピューティング) でインフラストラクチャの冗長性が提供されます。 この冗長性では、コロケーションのため、フェールオーバーの時間と、アプリケーションとデータベース サーバーの間のネットワーク待機時間が短縮されます。

同一ゾーン高可用性のアーキテクチャを示す図。

データ ファイルとログ ファイルは、ローカル冗長ストレージ (LRS) でホストされます。 スタンバイ サーバーは、プライマリ サーバーのストレージ アカウントからログ ファイルを継続的に読み取って再生します。これは、ストレージ レベルのレプリケーションによって保護されます。

フェールオーバーが発生した場合:

  • スタンバイ レプリカがアクティブにされます。
  • プライマリ サーバーのバイナリ ログ ファイルが、スタンバイ サーバーに続けて適用され、プライマリで最後にコミットされたトランザクションまでオンラインになります。

LRS のログには、プライマリ サーバーが使用できない場合でもアクセスできます。 この可用性により、データが失われないことが保証されます。 スタンバイ レプリカがアクティブにされて、バイナリ ログが適用された後は、現在のスタンバイ レプリカがプライマリ サーバーの役割を引き継ぎます。 クライアントの再接続時に、接続が新しいプライマリにリダイレクトされるように、DNS が更新されます。 フェールオーバーは、クライアント アプリケーションから完全に透過的で、ユーザーによる操作は必要ありません。 その後、HA ソリューションによって、可能であれば古いプライマリ サーバーが回復され、スタンバイとして配置されます。

プライマリ サーバーへのアプリケーションの接続には、データベース サーバー名が使用されます。 スタンバイ レプリカの情報が、直接アクセスのために公開されることはありません。 プライマリ サーバーの LRS でログ ファイルがフラッシュされた後で、コミットと書き込みが認められます。 プライマリとスタンバイ レプリカが同じゾーン内にあるため、アプリケーション サーバーとデータベース サーバーの間のレプリケーションの遅延が小さくなり、待機時間が短くなります。 依存するインフラストラクチャが特定の可用性ゾーンでダウンしたときは、同一ゾーンのセットアップによって高可用性は提供されません。 その可用性ゾーンですべての依存サービスがオンラインに戻るまで、ダウンタイムが発生します。

スナップショットとログ バックアップ両方の自動バックアップは、ローカル冗長ストレージ上でプライマリ データベース サーバーから実行されます。

Note

ゾーン冗長 HA と同一ゾーン HA の両方について:

  • 障害が発生した場合、スタンバイ レプリカがプライマリの役割を引き継ぐのに必要な時間は、プライマリ ストレージ アカウントからスタンバイへのバイナリ ログの再生にかかる時間によって異なります。 そのため、フェールオーバー時間を短縮するには、すべてのテーブルで主キーを使用することをお勧めします。 フェールオーバーの時間は、通常、60 から 120 秒です。
  • スタンバイ サーバーは、読み取りまたは書き込み操作には使用できません。 高速フェールオーバーを可能にするためのパッシブ スタンバイです。
  • プライマリ サーバーへの接続には、常に完全修飾ドメイン名 (FQDN) を使用します。 接続に IP アドレスを使用しないようにします。 フェールオーバーが発生した場合、プライマリ サーバーとスタンバイ サーバーの役割が切り替えられた後で、DNS A レコードが変更される可能性があります。 その変更により、接続文字列で IP アドレスが使用されている場合、アプリケーションが新しいプライマリ サーバーに接続できなくなるおそれがあります。

フェールオーバー プロセス

計画的: 強制フェールオーバー

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] をクリックすると確認できます。 自動フェールオーバーは、状態が [使用できません] として表され、[計画外] としてタグ付けされます。 例 - "Unavailable : A failover operation was triggered automatically (Unplanned)" (使用できません: フェールオーバー操作が自動的にトリガーされました (計画外))。 リソースがこの状態のまま長期間続く場合は、サポート チケットを開いてください。Microsoft がお手伝いします。

HA が有効になっているサーバーでの自動フェールオーバー検出のしくみ

プライマリ サーバーとセカンダリ サーバーには、次の 2 つのネットワーク エンドポイントがあります。

  • カスタマー エンドポイント: 顧客はこのエンドポイントを使用してインスタンスに接続し、クエリを実行します。
  • 管理エンドポイント: 管理コンポーネントへのサービス通信とバックエンド ストレージへの接続を目的として内部的に使用されます。

正常性モニター コンポーネントにより、次のチェックが絶えず実行されます。

  • ノードの管理ネットワーク エンドポイントに ping が送信されます。 このチェックが 2 回連続して失敗すると、自動フェールオーバー操作がトリガーされます。 OS の問題によりノードが利用できない、または応答しないなどのシナリオでは、管理コンポーネントとノード間のネットワークの問題がこの正常性チェックによって解決されます。
  • さらに、インスタンスに対して単純なクエリが実行されます。 クエリの実行に失敗すると、自動フェールオーバーがトリガーされます。 MySQL デーモンのクラッシュ、停止、ハングなどのシナリオや、バックエンド ストレージの問題は、この正常性チェックによって解決されます。

注意

アプリケーションとカスタマー ネットワーク エンドポイント (プライベート/パブリック アクセス) との間にネットワークの問題がある場合、その発生箇所がネットワーク パスであれ、エンドポイントであれ、クライアント側の DNS の問題であれ、このシナリオは、正常性チェックでは監視されません。 プライベート アクセスをご使用の場合、インスタンスのカスタマー ネットワーク エンドポイントに対するポート 3306 での通信が、VNet の NSG ルールによってブロックされていないことを確認してください。 パブリック アクセスの場合は、ファイアウォール規則が設定されていること、またポート 3306 でのネットワーク トラフィックが許可されていること (ネットワーク パスに他のファイアウォールが存在する場合) を確認してください。 クライアント アプリケーション側からの DNS 解決についても対処する必要があります。

高可用性の監視

ポータルのサーバーの [高可用性] ウィンドウにある [高可用性の状態 ] を使用して、サーバーの HA 構成の状態を特定できます。

Status 説明
NotEnabled HA が有効になっていません。
ReplicatingData スタンバイ サーバーは、HA サーバーのプロビジョニング時、または HA オプションが有効になっているときに、プライマリ サーバーとの同期処理中です。
FailingOver データベース サーバーは、プライマリからスタンバイにフェールオーバー中です。
Healthy HA オプションが有効になっています。
RemovingStandby HA オプションが無効になっており、削除プロセスが進行中の場合。

次のメトリックを使用して、HA サーバーの正常性を監視することもできます。

メトリックの表示名 メトリック ユニット 説明
HA IO の状態 ha_io_running State HA IO の状態は、HA レプリケーションの状態を示します。 メトリック値は、I/O スレッドが実行されている場合は 1、実行されていない場合は 0 です。
HA SQL の状態 ha_sql_running State HA SQL の状態は、HA レプリケーションの状態を示します。 メトリック値は、SQL スレッドが実行されている場合は 1、実行されていない場合は 0 です。
HA Replication Lag (HA レプリケーションのラグ) replication_lag 秒 レプリケーションのラグは、プライマリ サーバーで受信したトランザクションをスタンバイが再生する際に遅れる秒数です。

制限事項

高可用性を使用する場合、次の点にご注意ください。

  • ゾーン冗長高可用性は、フレキシブル サーバーが作成されるときにのみ設定できます。
  • 高可用性は、バースト可能なコンピューティング レベルではサポートされません。
  • 静的パラメーターの変更を取得するためにプライマリ データベース サーバーを再起動すると、スタンバイ レプリカも再起動されます。
  • HA ソリューションでは GTID が使用されるので、GTID モードが有効になります。 お使いのワークロードに、GTID を使用したレプリケーションに関する制限があるかどうかを調べてください。

Note

サーバーが作成する同一ゾーン HA ポストを有効にする場合は、HA を有効にする前に、サーバー パラメーター "enforce_gtid_consistency" と " gtid_mode " が ON に設定されていることを確認する必要があります。

Note

ストレージの自動拡張は、高可用性構成サーバーに対して既定で有効になっており、無効にすることはできません。

よく寄せられる質問 (FAQ)

  • 同じゾーンとゾーン冗長 HA 対応フレキシブル サーバーの SLA はどうなっていますか?

    Azure Database for MySQL の SLA 情報 - フレキシブル サーバーは Azure Database for MySQL の SLA にあります。

  • 高可用性 (HA) サーバーに対してはどのように請求されますか? HA で有効にされたサーバーには、プライマリ レプリカとセカンダリ レプリカがあります。 セカンダリ レプリカは、同じゾーンまたはゾーン冗長に含めることができます。 プライマリ レプリカとセカンダリ レプリカの両方について、プロビジョニングされたコンピューティングとストレージに対して請求されます。 たとえば、コンピューティングの 4 つの仮想コアとプロビジョニングされたストレージの 512 GB を持つプライマリがある場合、セカンダリ レプリカには 4 つの仮想コアと 512 GB のプロビジョニングされたストレージも含まれます。 ゾーン冗長 HA サーバーは、8 個の仮想コアと 1,024 GB のストレージに対して請求されます。 バックアップ ストレージ ボリュームによっては、バックアップ ストレージの請求が発生する場合もあります。

  • 読み取りまたは書き込み操作にスタンバイ レプリカを使用できますか?
    スタンバイ サーバーは、読み取りまたは書き込み操作には使用できません。 高速フェールオーバーを可能にするためのパッシブ スタンバイです。

  • フェールオーバーが発生するとデータが失われますか?
    ZRS のログには、プライマリ サーバーが使用できない場合でもアクセスできます。 この可用性により、データが失われないことが保証されます。 スタンバイ レプリカがアクティブにされて、バイナリ ログが適用された後は、それがプライマリ サーバーの役割を引き継ぎます。

  • フェールオーバーの後で、何かを実行する必要がありますか?
    フェールオーバーは、クライアント アプリケーションから完全に透過的です。 何らかのアクションをとる必要はありません。 アプリケーションで必要なのは、接続に対して再試行ロジックを使用することだけです。

  • スタンバイ レプリカに特定のゾーンを選択しないとどうなりますか。 後でゾーンを変更できますか?
    ゾーンを選択しないと、ランダムに選択されます。 これがプライマリ サーバーに使用されるものになります。 後でゾーンを変更するには、[高可用性] ペインで [高可用性] を [無効] に設定した後、設定を [ゾーン冗長] に戻してゾーンを選択します。

  • プライマリ レプリカとスタンバイ レプリカの間のレプリケーションは同期的ですか?
    プライマリとスタンバイの間のレプリケーションは、MySQL での半同期モードに似ています。 トランザクションがコミットされるとき、必ずしもスタンバイにコミットされるとは限りません。 ただし、プライマリが使用できないときは、データが失われないように、スタンバイによってプライマリからすべてのデータ変更がレプリケートされます。

  • 計画外のすべての障害で、スタンバイ レプリカへのフェールオーバーが行われますか?
    データベースのクラッシュやノードの障害が発生すると、フレキシブル サーバー VM が同じノードで再起動されます。 同時に、自動フェールオーバーがトリガーされます。 フェールオーバーが完了する前にフレキシブル サーバー VM の再起動が成功した場合、フェールオーバー操作は取り消されます。 プライマリ レプリカとしてどのサーバーを使用するかは、最初に終了するプロセスによって決まります。

  • HA を使用すると、パフォーマンスに影響がありますか?
    ゾーン冗長 HA の場合、読み取りワークロードについては可用性ゾーン全体でパフォーマンスに大きな影響はありませんが、書き込みクエリの待ち時間が最大 40% 短くなることがあります。 書き込み待ち時間の増加は可用性ゾーン全体の同期レプリケーションに起因します。 書き込み待ち時間の影響は通常、同じゾーン HA と比較したとき、ゾーン冗長 HA で 2 倍になります。 同一ゾーン HA の場合、プライマリとスタンバイのレプリカが同じゾーン内にあるため、レプリケーションの待ち時間が短くなり、結果的に同期書き込みの待ち時間が短くなります。 要約すると、書き込み待ち時間は可用性よりも重要なら、同一ゾーン HA を選択することをお勧めしますが、データの可用性と回復性が書き込み待ち時間よりも重要なら、ゾーン冗長 HA を選択する必要があります。 HA セットアップの待ち時間短縮の影響を正確に計測する場合、ワークロードのパフォーマンス テストを実行し、情報を得た上で判断することをお勧めします。

  • HA サーバーのメンテナンスはどのように行われますか?
    コンピューティングのスケーリングやマイナー バージョンのアップグレードなどの計画されたイベントは、まず元のスタンバイ インスタンスで発生し、続いて計画されたフェールオーバー操作がトリガーされてから、元のプライマリ インスタンス上で動作します。 HA サーバーの予定メンテナンス期間は、フレキシブル サーバーの場合と同じように設定できます。 ダウンタイムの長さは、HA が無効になっているときの Azure Database for MySQL - フレキシブル サーバー インスタンスのダウンタイムと同じになります。

  • HA サーバーのポイントインタイム リストア (PITR) を行うことはできますか?
    HA が有効になっている Azure Database for MySQL - フレキシブル サーバー インスタンスから、HA が無効になっている新しい Azure Database for MySQL - フレキシブル サーバー インスタンスへの PITR を行うことができます。 ソース サーバーがゾーン冗長 HA で作成されている場合は、復元されたサーバーでゾーン冗長 HA または同一ゾーン HA を後で有効にできます。 ソース サーバーが同一ゾーン HA で作成されている場合、復元されたサーバーで有効にできるのは同一ゾーン HA だけです。

  • サーバーの作成後に、サーバーで HA を有効にすることはできますか?
    ゾーン冗長 HA は、サーバーの作成時に有効にする必要があります。 同一ゾーン HA は、サーバーを作成した後で有効にすることができます。 同一ゾーン HA を有効にする前に、サーバー パラメーターの "enforce_gtid_consistency" と "gtid_mode" が ON に設定されていることを確認してください。

  • サーバーの作成後に、サーバーの HA を無効にすることはできますか?
    サーバーを作成した後で、サーバーの HA を無効にできます。 課金はすぐに停止します。

  • ダウンタイムを軽減するにはどうすればよいですか?
    HA を使用していない場合でも、アプリケーションのダウンタイムを軽減できる必要があります。 計画的なパッチ、マイナー バージョン アップグレード、またはコンピューティングのスケーリングなどのお客様が開始する操作のようなサービス ダウンタイムは、予定メンテナンス期間の間に実行できます。 Azure によって開始されるメンテナンス タスクがアプリケーションに与える影響を軽減するには、アプリケーションに対する影響が最も小さい曜日と時刻に、それらをスケジュールできます。

  • HA が有効になっているサーバーに対して読み取りレプリカを使用できますか?
    はい。読み取りレプリカは HA サーバーではサポートされています。

  • HA サーバーにデータイン レプリケーションを使用できますか?
    高可用性 (HA) 対応サーバーのデータイン レプリケーションのサポートは、GTID ベースのレプリケーションでのみ使用できます。 GTID を使用したレプリケーションのストアド プロシージャは、mysql.az_replication_with_gtid という名前ですべての HA 対応サーバーで使用できます。

  • ダウンタイムを短くするため、サーバーの再起動中、またはスケールアップやスケールダウンの間に、スタンバイ サーバーにフェールオーバーできますか?
    現在、Azure Database for MySQL フレキシブル サーバーでは、スケールアップ/スケールダウンや計画メンテナンスなどの HA 操作を最適化してダウンタイムを短縮できるように計画フェールオーバーを利用しています。 このような操作が開始されると、最初に元のスタンバイ インスタンスで動作し、次に計画フェールオーバー操作をトリガーしてから、元のプライマリ インスタンスで動作します。

  • サーバーの可用性モード (ゾーン冗長 HA/同一ゾーン) を変更できますか
    ゾーン冗長 HA モードを有効にしてサーバーを作成した場合は、ゾーン冗長 HA から同一ゾーンに変更できます。その逆も可能です。 可用性モードを変更するには、[高可用性] ペインで [高可用性] を [無効] に設定した後、設定を [ゾーン冗長] または [同一ゾーン] に戻し、[高可用性モード] を選択します。

次のステップ