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

重要

Azure Database for MySQL - フレキシブル サーバーは現在、パブリック プレビュー段階にあります。

Azure Database for MySQL フレキシブル サーバー (プレビュー) では、ゾーン冗長 の高可用性オプションを使用して、自動フェールオーバーによる高可用性を構成できます。 ゾーン冗長構成でデプロイされた場合、フレキシブル サーバーによって自動的に、スタンバイ レプリカがプロビジョニングされ、別の可用性ゾーンで管理されます。 ストレージ レベルのレプリケーションを使用すると、データは、セカンダリ ゾーン内のスタンバイ サーバーに 同期的にレプリケート され、フェールオーバー後のデータ損失をゼロにすることができます。 フェールオーバーは、クライアント アプリケーションから完全に透過的で、ユーザーによる操作は必要ありません。 スタンバイ サーバーは、読み取りまたは書き込み操作に使用できるものではなく、高速フェールオーバーを可能にするためのパッシブ スタンバイです。 フェールオーバー時間の範囲は、通常、60 秒から 120 秒までです。

ゾーン冗長による高可用性構成では、ユーザーが開始したコンピューティングのスケーリング操作などの計画イベント中、および基になるハードウェアやソフトウェアの障害、ネットワーク障害、可用性ゾーンの障害などの予定外のイベント中でも、自動フェールオーバーを行うことができます。

ゾーン冗長による高可用性のビュー

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

プライマリ サーバーは、リージョンと特定の可用性ゾーンにデプロイされます。 高可用性を選択すると、コンピューティング レベル、コンピューティング サイズ、ストレージ サイズ、ネットワーク構成など、プライマリ サーバーと同じ構成のスタンバイ レプリカ サーバーが自動的にデプロイされます。 ログ データは、スタンバイ レプリカに同期的にレプリケートされ、どのような障害状況でもデータ損失がゼロになることが保証されます。 自動バックアップ、両方のスナップショット、ログ バックアップは、プライマリ データベース サーバーから実行されます。

HA の正常性は、概要ページで継続的に監視され、報告されます。

さまざまなレプリケーションの状態を次に示します。

状態 説明
NotEnabled ゾーン冗長による HA が有効ではありません
CreatingStandby 新しいスタンバイを作成中です
ReplicatingData スタンバイの作成後、そのスタンバイがプライマリ サーバーにキャッチアップ中です。
FailingOver データベース サーバーは、プライマリからスタンバイにフェールオーバー中です。
Healthy ゾーン冗長による HA は、安定した状態で正常です。
RemovingStandby ユーザーの操作に基づいて、スタンバイ レプリカを削除中です。

長所

ゾーン冗長による HA 機能を使用する場合、次のような利点があります。

  • スタンバイ レプリカでは、仮想コア、ストレージ、ネットワーク設定 (VNET、ファイアウォール) など、プライマリとまったく同じ VM 構成でデプロイが行われます。
  • 高可用性を無効にすることによってスタンバイ レプリカを削除できます。
  • 自動バックアップはスナップショットベースで、プライマリ データベース サーバーから実行され、ゾーン冗長ストレージに格納されます。
  • フェールオーバー時には、高可用性が有効になっていれば、Azure Database for MySQL フレキシブル サーバーが自動的にスタンバイ レプリカにフェールオーバーされます。 高可用性の設定では、プライマリ サーバーが監視され、オンラインに戻されます。
  • クライアントは常に、プライマリ データベース サーバーに接続されます。
  • データベースのクラッシュやノードの障害が発生すると、最初に、同じノードで再起動が試行されます。 それが失敗した場合は、自動フェールオーバーがトリガーされます。
  • サーバーを再起動して静的サーバー パラメーターの変更を取得できます。

安定状態の操作

アプリケーションは、データベース サーバー名を使用してプライマリ サーバーに接続されます。 スタンバイ レプリカの情報は、直接アクセスに対して公開されません。 コミットと書き込みは、ログ ファイルがプライマリ サーバーのディスクとスタンバイ レプリカの両方に同期的に保持された後にのみ、アプリケーションによって認識されます。 この追加のラウンドトリップ要件のために、アプリケーションでは、書き込みとコミットの待機時間が長くなることが予想されます。 高可用性の正常性をポータルで監視できます。

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

ビジネス継続性を確保するには、計画イベントと予定外のイベントのためのフェールオーバー プロセスが必要です。

計画イベント

計画されたダウンタイム イベントとしては、定期的なソフトウェア更新、マイナー バージョン アップグレードなどの Azure によってスケジュールされたアクティビティ、またはコンピューティングのスケーリング操作やストレージのスケーリング操作などの顧客によって開始されるアクティビティがあります。 これらの変更はすべて、まずスタンバイ レプリカに適用されます。 その間、アプリケーションはプライマリ サーバーにアクセスし続けます。 スタンバイ レプリカが更新された後、プライマリ サーバーの接続がドレインされ、フェールオーバーがトリガーされます。これにより、スタンバイ レプリカがアクティブ化され、DNS レコードを更新することにより、同じデータベース サーバー名を持つプライマリになります。 クライアント接続が切断され、再接続が必要になります。そうすれば、動作を再開できます。 新しいスタンバイ サーバーは、古いプライマリと同じゾーン内に確立されます。 全体的なフェールオーバー時間は、60 から 120 秒になると予想されます。

注意

コンピューティングのスケーリング操作の場合、セカンダリ レプリカ サーバーをスケーリングした後、プライマリ サーバーをスケーリングします。 関連するフェールオーバーはありません。

フェールオーバー プロセス - 予定外のイベント

予定外のサービス ダウンタイムとしては、データベースの可用性に影響を与えるソフトウェアのバグや、コンピューティング、ネットワーク、ストレージ障害などのインフラストラクチャの障害、停電があります。 データベースが使用できなくなった場合、スタンバイ レプリカへのレプリケーションは停止され、スタンバイ レプリカがアクティブ化されてプライマリ データベースになります。 DNS が更新された後、クライアントはデータベース サーバーに再接続され、操作を開始します。 全体的なフェールオーバー時間は、60 から 120 秒になると予想されます。 ただし、フェールオーバーの時点でのプライマリ データベース サーバー内のアクティビティ (大規模なトランザクションや復旧時間など) によっては、フェールオーバーがこれより長くなる可能性があります。

強制フェールオーバー

Azure Database for MySQL 強制フェールオーバーによって手動で強制的にフェールオーバーできるため、この機能をアプリケーション シナリオでテストして、障害が発生した場合に備えることができます。 強制フェールオーバーでトリガーされるフェールオーバーによりスタンバイ レプリカがアクティブになってプライマリ サーバーになることで、スタンバイ サーバーはプライマリ サーバーに切り替わります。このとき DNS レコードが更新されることで、同じデータベース サーバー名が使用されます。 最初のプライマリ サーバーは再起動して、スタンバイ レプリカに切り替わります。 クライアント接続は切断されて、操作を再開するためには再接続が必要になります。 現在のワークロードと最後のチェックポイントに応じて、全体的なフェールオーバーの時間が測定されます。 一般には、60 秒から 120 秒の範囲であると予想されます。

メンテナンス期間のスケジュール

フレキシブル サーバーには、メンテナンス スケジュール機能が用意されています。この機能では、1 日のうちで、パッチやマイナー バージョン アップグレードなどの Azure メンテナンス作業が行われる 30 分間を任意で選択できます。 高可用性が構成されているフレキシブル サーバーの場合、これらのメンテナンス アクティビティは、最初にスタンバイ レプリカで実行されます。

ポイントインタイム リストア

フレキシブル サーバーは高可用性で構成され、データが同期的にレプリケートされるため、スタンバイ サーバーはプライマリに合わせて最新の状態です。 プライマリ上のユーザー エラー (テーブルの誤った削除や不正な更新など) はすべて、スタンバイに忠実にレプリケートされます。 そのため、スタンバイを使用して、このような論理エラーから復旧することはできません。 これらの論理エラーから復旧するには、エラーが発生する直前の時点へのポイントインタイム リストアを実行する必要があります。 フレキシブル サーバーのポイントインタイム リストア機能を使用すると、高可用性で構成されたデータベースを復元するとき、新しいデータベース サーバーは、ユーザー指定の名前を持つ新しいフレキシブル サーバーとして復元されます。 その後、データベース サーバーからオブジェクトをエクスポートし、それを運用データベース サーバーにインポートできます。 同様に、テストや開発の目的でデータベース サーバーを複製する場合、または他の目的で復元する場合、最新の復元ポイントまたはカスタムの復元ポイントのいずれかを選択できます。 復元操作により、単一ゾーンのフレキシブル サーバーが作成されます。

ダウンタイムを軽減する

ゾーン冗長による HA 機能を使用しない場合でも、アプリケーションのダウンタイムを軽減できる必要があります。 スケジュールされたパッチ、マイナー バージョン アップグレード、ユーザーが開始した操作などのサービス ダウンタイムの計画は、スケジュールされたメンテナンス期間の一部として実行できます。 スケジュールされたパッチ、マイナー バージョン アップグレード、ユーザーが開始した操作 (コンピューティングのスケーリングなど) などの予定されたサービス ダウンタイムによって、ダウンタイムが発生します。 Azure によって開始されるメンテナンス タスクがアプリケーションに与える影響を軽減するために、アプリケーションに対する影響が最も少ない曜日と時刻にタスクをスケジュールすることを選択できます。

データベースのクラッシュやサーバーの障害などの予定外のダウンタイム イベントが発生すると、影響を受けたサーバーが同じゾーン内で再起動されます。 まれですが、ゾーン全体が影響を受けた場合は、データベースをリージョン内の別のゾーンで復元することができます。

ゾーン冗長に関する注意事項

ゾーン冗長による高可用性を使用する場合、次の点に注意してください。

  • 高可用性は、フレキシブル サーバーの作成時に のみ 設定できます。
  • 高可用性は、バースト可能なコンピューティング レベルではサポートされません。
  • 別の可用性ゾーンへの同期レプリケーションのために、プライマリ データベース サーバーで書き込みとコミットの待機時間が長くなる場合があります。
  • スタンバイ レプリカを読み取り専用クエリに使用することはできません。
  • フェールオーバーの時点でのプライマリ サーバー上のアクティビティによっては、フェールオーバーが完了するまでに最大 60 から 120 秒かかることがあります。
  • 静的パラメーターの変更を取得するためにプライマリ データベース サーバーを再起動すると、スタンバイ レプリカも再起動されます。
  • ゾーン冗長による高可用性サーバーに対して読み取りレプリカを構成することはサポートされていません。
  • 顧客が開始する管理タスクの構成を、管理されたメンテナンス期間中に自動化することはできません。
  • コンピューティングのスケーリングやマイナー バージョン アップグレードなどの予定イベントは、プライマリとスタンバイの両方で同時に発生します。

次のステップ