Azure Database for MySQL - フレキシブル サーバーでのビジネス継続性の概要

  • [アーティクル]

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

Azure Database for MySQL フレキシブル サーバーを使用すると、計画的および計画外の停止が発生した場合にデータベースを保護するビジネス継続性機能を実現できます。 自動バックアップや高可用性などの機能は、復旧時間とデータ損失の可能性が異なる、さまざまなレベルのフォールト保護に対応します。 障害から保護するようにアプリケーションを設計する際には、各アプリケーションの目標復旧時間 (RTO) と目標復旧時点 (RPO) を考慮する必要があります。 RTO はダウンタイムの許容範囲であり、RPO はデータベース サービスの中断後のデータ損失の許容範囲です。

次の表は、Azure Database for MySQL フレキシブル サーバーが提供する機能を示しています。

機能 説明 制限事項
バックアップ & 復旧 このサービスを使用すると、データベース ファイルの毎日のバックアップが自動的に実行され、トランザクション ログが継続的にバックアップされます。 バックアップは、1 ～ 35 日の任意の期間保持できます。 バックアップ保有期間内の任意の時点にデータベース サーバーを復元できます。 回復時間は、復元するデータのサイズとログ回復を実行する時間によって異なります。 詳細については、「概念 - バックアップと復元」を参照してください。 バックアップ データはリージョン内に残されます
ローカル冗長バックアップ サービスのバックアップが、リージョン内および同じ可用性ゾーン内のローカル冗長ストレージに自動的かつ安全に格納されます。 ローカル冗長バックアップは、プライマリ リージョンの 1 つの物理的な場所内で、サーバーのバックアップ データ ファイルを 3 回レプリケートします。 ローカル冗長バックアップ ストレージでは、オブジェクトに年間 99.999999999% (9 が 11 個) 以上の持続性が提供されます。 詳細については、「概念 - バックアップと復元」を参照してください。 すべてのリージョンで適用可能
geo 冗長バックアップ サービスのバックアップを、作成時に geo 冗長として構成できます。 geo 冗長性を有効にすると、リージョンの回復性を提供するために、プライマリ リージョンのペアになっているリージョンにサーバーのバックアップ データ ファイルがレプリケートされます。 geo 冗長バックアップ ストレージでは、オブジェクトに年間 99.99999999999999% (9 が 16 個) 以上の持続性が提供されます。 詳細については、「概念 - バックアップと復元」を参照してください。 すべての Azure のペアになっているリージョンで使用可能
ゾーン冗長の高可用性 サービスを、リージョン内の 2 つの異なる可用性ゾーンにプライマリ サーバーとスタンバイ サーバーをデプロイする高可用性モードでデプロイできます。 ゾーン冗長高可用性は、ゾーン レベルの障害から保護し、計画的および計画外のダウンタイム イベント中のアプリケーションのダウンタイムを削減するのにも役立ちます。 プライマリ サーバーからのデータは、スタンバイ レプリカに同期的にレプリケートされます。 ダウンタイム イベントが発生すると、データベース サーバーは自動的にスタンバイ レプリカにフェールオーバーされます。 詳細については、「概念 - 高可用性」を参照してください。 汎用および Business Critical コンピューティング レベルでサポートされます。 複数のゾーンが使用可能なリージョンでのみ利用できます。
Premium ファイル共有 データベース ファイルは、耐久性が高く信頼性に優れた Azure Premium ファイル共有に格納されます。これにより、自動データ復旧機能を備えた可用性ゾーン内に格納されたレプリカの 3 つのコピーを使用してデータの冗長性を実現できます。 詳細については、Premium ファイル共有に関するページを参照してください。 可用性ゾーン内に格納されるデータ

計画的なダウンタイムの軽減

ダウンタイムが発生する計画メンテナンスのシナリオを次に示します。

シナリオ Process
コンピューティングのスケーリング (ユーザー) コンピューティングのスケーリング操作を実行すると、スケーリングされたコンピューティング構成を使用して新しいフレキシブル サーバーがプロビジョニングされます。 既存のデータベース サーバーでは、アクティブなチェックポイントを完了でき、クライアント接続がドレインされ、コミットされていないトランザクションが取り消され、サーバー自体がシャットダウンされます。 その後、ストレージが新しいサーバーに接続され、データベースが開始されます。これにより、クライアント接続を受け入れる前に、必要に応じて回復が実行されます。
新しいソフトウェアのデプロイ (Azure) 新機能のロールアウトやバグの修正は、サービスの計画メンテナンスの一環として自動的に行われ、ユーザーはそれらのアクティビティがいつ発生するかをスケジュールできます。 詳細については、ドキュメントを参照し、自身のポータルを確認してください
マイナー バージョンのアップグレード (Azure) Azure Database for MySQL フレキシブル サーバーは、Azure によって決定されたマイナー バージョンにデータベース サーバーに自動的にパッチを適用します。 これは、サービスの計画的なメンテナンスの一環として行われます。 これにより、秒単位の短いダウンタイムが発生し、データベース サーバーは新しいマイナー バージョンで自動的に再起動されます。 詳細については、ドキュメントを参照し、自身のポータルを確認してください。

フレキシブル サーバーがゾーン冗長の高可用性で構成されている場合、フレキシブル サーバーは最初にスタンバイ サーバーで操作を実行し、次にフェールオーバーを行わずにプライマリ サーバーで操作を実行します。 詳細については、「概念 - 高可用性」を参照してください。

計画外のダウンタイムの軽減

計画外のダウンタイムは、基になるハードウェアの障害、ネットワークの問題、ソフトウェアのバグなど、予期しない障害の結果として発生する可能性があります。 データベース サーバーが予期せず停止した場合、高可用性 [HA] を使用して構成されている場合は、スタンバイ レプリカがアクティブ化されます。 それ以外の場合は、新しいデータベース サーバーが自動的にプロビジョニングされます。 計画外のダウンタイムは回避できませんが、フレキシブル サーバーでは、データベース サーバーとストレージ レイヤーの両方で、ユーザーの介入を必要とすることなく復旧操作を自動的に実行してダウンタイムを軽減します。

計画外のダウンタイム: 障害シナリオとサービス復旧

計画外の障害シナリオと復旧プロセスを次に示します。

シナリオ 復旧プロセス [非 HA] 復旧プロセス [HA]
データベース サーバーの障害 基になるハードウェアの障害が原因でデータベース サーバーが停止した場合、アクティブな接続は切断され、処理中のすべてのトランザクションは中止されます。 Azure はデータベース サーバーの再起動を試みます。 成功した場合は、データベース復旧が実行されます。 再起動に失敗した場合、データベース サーバーの再起動は別の物理ノードで試行されます。

復旧時間 (RTO) は、大規模なトランザクションやデータベース サーバーの起動プロセス中に実行される復旧の量など、障害発生時のアクティビティなど、さまざまな要因によって異なります。 RPO は 0 です。コミットされたトランザクションではデータ損失は発生しません。 MySQL データベースを使用するアプリケーションによって、切断された接続や失敗したトランザクションが検出され、再試行するように構築されている必要があります。 アプリケーションが再試行すると、接続は、新しく作成されたデータベース サーバーに転送されます。

その他の使用可能なオプションは、バックアップから復元されます。 ペアのリージョンから PITR または geo リストアの両方を使用できます。
PITR : RTO: 変動、RPO=0sec
geo リストア: RTO: 場合により変動 RPO < 1 時間。

また、 読み取りレプリカ を DR ソリューションとして使用できます。 レプリケーションを停止すると、読み取りレプリカが読み取り/書き込み可能になります (スタンドアロンの後、アプリケーション トラフィックをこのデータベースにリダイレクトします)。 ほとんどの場合、RTO は数分、RPO < は 1 時間です。 RTO と RPO は、サイト間の待機時間、送信するデータの量、重要なプライマリ データベース書き込みワークロードなど、さまざまな要因に応じて、場合によってははるかに高くなる可能性があります。		 データベース サーバーの障害または回復不可能なエラーが検出されると、スタンバイ データベース サーバーがアクティブ化され、ダウンタイムが短縮されます。 詳細については、HA の概念に関するページを参照してください。 RTO は 60 から 120 秒と想定され、RPO = 0 です。

注:回復プロセス [非 HA] のオプションもここで適用できます。
ストレージの障害 アプリケーションは、ディスク障害や物理ブロックの破損など、ストレージ関連の問題の影響を一切認識しません。 データが 3 つのコピーに格納されるので、データのコピーは存続しているストレージから提供されます。 ブロックの破損は自動的に修正されます。 データのコピーが失われると、データの新しいコピーが自動的に作成されます。

すべてのコピーが破損しているという、まれな最悪のシナリオでは、geo リストア (ペアのリージョン) からの復元を使用できます。 RPO < 1 時間で、RTO は場合によって変動します。

前述のように、読み取りレプリカを DR ソリューションとして使用することもできます。		 このシナリオでは、オプションは復旧プロセス [非 HA] の場合と同じです。
論理/ユーザー エラー 誤って破棄されたテーブルや間違って更新されたデータなどのユーザーエラーからの復旧には、エラーが発生する直前の時間までデータを復元および復旧することによる、特定の時点への復旧 (PITR) の実行が含まれます。

削除されたフレキシブル サーバー リソースは、サーバーを削除した時点から 5 日以内であれば復元できます。 削除されたサーバーの復元方法については、手順を示したドキュメントを参照してください (../flexible-server/how-to-restore-dropped-server.md)。 デプロイ後のサーバー リソースを誤って削除または予期しない変更から保護するために、管理者は管理ロックを使用できます。		 これらのユーザー エラーは、すべてのユーザー操作がスタンバイにもレプリケートされるため、高可用性では保護されません。 このシナリオでは、オプションは復旧プロセス [非 HA] の場合と同じです。
可用性ゾーンの障害 まれにしか起こらないことですが、ゾーン レベルの障害から復旧する場合は、ペアのリージョンから geo リストアを実行できます。 RPO < 1 時間で、RTO は場合によって変動します。

他の可用性ゾーンにレプリカを作成することで、読み取りレプリカを DR ソリューションとして使用できます。 RTO と RPO は、前述の場合と同様です。		 ゾーン冗長 HA を有効にしている場合、フレキシブル サーバーではスタンバイ サイトへの自動フェールオーバーを実行します。 詳細については、「HA の概念」を参照してください。 RTO は 60 から 120 秒と想定され、RPO = 0 です。

その他の使用可能なオプションは、バックアップから復元されます。 ペアのリージョンから PITR または geo リストアの両方を使用できます。
PITR : RTO: 変動、RPO=0 秒
Geo Restore : RTO: Varies, RPO <1 h

注:同じゾーン HA が有効になっている場合、オプションは復旧プロセス [非 HA] の場合と同じです。
リージョンの障害 まれにしか起こらないことですが、リージョン レベルの障害から復旧する場合は、同じサブスクリプションで利用可能な最新の geo 冗長バックアップを使用して新しいサーバーを作成し、最新のデータを取得することで、データベースの復旧を実行できます。 選択したリージョンに新しいフレキシブル サーバーがデプロイされます。 復元にかかる時間は、前回のバックアップと、復旧するトランザクション ログの数によって異なります。 ほとんどの場合、RPO < 1 時間で、RTO は場合によって変動します。 このシナリオでは、オプションは復旧プロセス [非 HA] の場合と同じです。

要件と制限

リージョンのデータ所在地

既定では、Azure Database for MySQL フレキシブル サーバーは、デプロイ先のリージョンから顧客データを移動または格納しません。 ただし、必要に応じて、geo 冗長バックアップを有効にするか、別のリージョンにデータを格納するためのリージョン間レプリケーションを設定することもできます。

次のステップ