次の方法で共有

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

  • [アーティクル]

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

次の表は、Azure Database for MySQL フレキシブル サーバーが提供する機能をまとめたものです。

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

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

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

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

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

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

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

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

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

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

復旧時間 (RTO) は、大規模なトランザクションや、データベース サーバーの起動プロセス中に実行される復旧の量など、障害発生時のアクティビティを含め、さまざまな要因によって異なります。 コミットされたトランザクションではデータ損失が発生しないことが想定されているため、RPO はゼロになります。 MySQL データベースを使用するアプリケーションによって、切断された接続や失敗したトランザクションが検出され、再試行するように構築されている必要があります。 アプリケーションが再試行すると、接続は、新しく作成されたデータベース サーバーに転送されます。
その他の使用可能なオプションは、バックアップから復元されます。 ペアのリージョンから PITR または geo リストアの両方を使用できます。
PITR : RTO: 場合により変動 RPO = 0 秒
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 を有効にしている場合、フレキシブル サーバーではスタンバイ サイトへの自動フェールオーバーを実行します。 詳細については、「Azure Database for MySQL - フレキシブル サーバーでの高可用性の概念」を参照してください。 RTO は 60 から 120 秒と想定され、RPO = 0 です。
その他の使用可能なオプションは、バックアップから復元されます。 ペアのリージョンから PITR または geo リストアの両方を使用できます。
PITR : RTO: 場合により変動 RPO = 0 秒
geo リストア: RTO: 場合により変動、RPO < 1 時間。
注:同じゾーンで HA が有効になっている場合、オプションは復旧プロセス [非 HA] のオプションと同じです。
リージョンの障害 まれにしか起こらないことですが、リージョン レベルの障害から復旧する場合は、同じサブスクリプションで利用可能な最新の geo 冗長バックアップを使用して新しいサーバーを作成し、最新のデータを取得することで、データベースの復旧を実行できます。 選択したリージョンに新しいフレキシブル サーバーがデプロイされます。 復元にかかる時間は、前回のバックアップと、復旧するトランザクション ログの数によって異なります。 ほとんどの場合、RPO < 1 時間で、RTO は場合によって変動します。 このシナリオでは、オプションは復旧プロセス [非 HA] の場合と同じです。

要件と制限

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

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

関連するコンテンツ