事業継続とディザスター リカバリーのオプションを比較する
Azure Database for MySQL - フレキシブル サーバーは、計画的または計画外の停止が発生した場合にデータベースを保護するための事業継続機能を提供します。 さまざまな種類の停止に対処するため、復旧時間やデータ損失のリスクが異なる、さまざまなレベルの障害保護を適用できます。
ダウンタイムの例
以下では、計画的と計画外両方のダウンタイムのシナリオの例をいくつか示します。
計画的なダウンタイムのシナリオ
最も一般的な 2 つの計画的ダウンタイムのシナリオは、ユーザーによって開始されるコンピューティングのスケーリングと、Azure によって実行される予定メンテナンスです。
コンピューティングのスケーリング操作を実行すると、Azure は要求されたコンピューティング構成で新しい MySQL フレキシブル サーバーをプロビジョニングします。 既存のサーバーは、アクティブなチェックポイントが完了するのを許可し、既存の接続をドレインし、コミットされていないトランザクションを取り消した後、シャットダウンします。 この時点で、Azure は既存のサーバーのストレージを新しいサーバーにアタッチして、データベースを起動します。 その後、データベースは、クライアント接続の受け入れを続ける前に、必要な復旧を実行します。
新機能とバグ修正は、サービスの計画メンテナンスの一環として自動的に行われます。 計画メンテナンスではマイナー バージョンのアップグレード パッチも適用され、数秒のダウンタイムが発生します。 後の「予定されたダウンタイムとメンテナンス期間」セクションで説明されているように、それらのアクティビティはスケジュールできます。
計画外のダウンタイム
データベースは、次のようないくつかの理由で、予期せずダウンすることがあります。
- データベース ハードウェアの障害。
- ストレージ ドライブの障害。
- アプリケーションまたはユーザーのエラー (テーブルを誤って削除した場合など)。
- 可用性ゾーンとリージョンの障害。
高可用性 (HA) が有効になっていない場合、Azure は、失われたデータのコピー、サーバーの再起動、さらには別の物理ノードでのサーバーの起動などの復旧を試みます。 HA を有効にすると、次のセクションで説明するように、このようなダウンタイムを減らしたり、なくしたりできます。
高可用性
Azure Database for MySQL – フレキシブル サーバーに用意されている自動フェールオーバーによる HA では、コミットされたデータが失われず、データベースが単一障害点にならないように設計されたソリューションが提供されます。 HA を構成してあると、MySQL フレキシブル サーバーはスタンバイ レプリカを自動的にプロビジョニングおよび管理します。
高可用性には、フォールト トレランスと待ち時間のトレードオフが異なる、ゾーン冗長と同一ゾーンの 2 種類があります。
ゾーン冗長 HA
ゾーン冗長 HA では、複数の可用性ゾーンにまたがる冗長性が提供され、ゾーン全体がダウンした場合でも復旧できる最高レベルの可用性が実現されます。 ゾーン冗長 HA 構成を使うと待ち時間が長くなるため、これがアプリケーションで許容されるかどうかを判断してください。 さらに、ゾーン冗長 HA 構成を使うには、全体的な操作が確実に続行されるよう、データベース クライアント アプリケーションもゾーン冗長にする必要があります。
同一ゾーン HA
同一ゾーン HA 構成では、プライマリとスタンバイ サーバーが同じ可用性ゾーンに存在するため、待ち時間が最小になります。 一部のユース ケースでは低遅延が必要になることがありますが、同一ゾーン HA 構成では、可用性ゾーンがダウンした場合、MySQL フレキシブル サーバーを復旧するのでダウンタイムが長くなります。
ゾーン冗長 HA とは異なり、同一ゾーン HA は、Azure Database for MySQL - フレキシブル サーバーをサポートするすべてのリージョンで利用できます。
バックアップと復元
サーバーのバックアップは、事業継続性戦略の重要な要素です。 Azure Database for MySQL - フレキシブル サーバーは、データベースをホストしているリージョン内のローカル冗長ストレージに安全に格納されるバックアップを、自動的に作成します。 障害やデータの破損 (アプリケーションのバグや開発エラーなど) が発生した場合は、これらのバックアップを使って、データベースを特定の時点に復元できます。
バックアップには 2 つの種類あります。 自動バックアップでは、MySQL フレキシブル サーバーは、データベース データ ファイルとそれに関連するトランザクション ログのスナップショットを取得します。 自動スナップショット バックアップは 1 日に 1 回行われ、トランザクション ログ バックアップは 5 分ごとに行われます。 バックアップが失敗した場合、サーバーはバックアップが成功するまで 20 分ごとに再試行します。
ユーザーは、オンデマンド バックアップを使って、いつでもデータベースのバックアップを作成できます。 どちらの種類のバックアップでも、バックアップ ファイルは既定で 7 日間保持されます。 ただし、ビジネス ニーズに基づいて、保持期間の値を 1 日から 35 日の範囲で構成できます。
現在はパブリック プレビューである長期保有機能を使って、バックアップを最大 10 年間保持できます。 長期バックアップ ソリューションは、自動 Azure Database for MySQL バックアップとは別に、またはそれに加えて使われる場合があります。 長期バックアップは、お客様が管理するスケジュールまたはオンデマンドで実行できます。 バックアップは、Azure Backup マネージド ストレージ アカウントの、個別のセキュリティ ドメインと障害ドメインに格納されます。
データベースのバックアップに加えて、ユーザーは Azure Blob Storage にバックアップ ファイルをエクスポートすることができ、後でそれを移行、データ復旧、アーカイブに使用できます。 オンデマンド エクスポートは現在パブリック プレビューであり、パブリック クラウド リージョンでのみ使用できます。
バックアップ ファイルを格納するには、いくつかのストレージ オプションから選択できます。
ローカル冗長ストレージ (同じデータセンター、同じゾーン) では、バックアップ ファイルはデータベースと同じデータセンターに格納されます。 このオプションでは、バックアップ オブジェクトに対する持続性は 1 年間で 99.999999999% (9 が 11 個) です。 既定では、HA ではないサーバーまたは同一ゾーン HA のサーバーは、ローカル冗長ストレージを使います。
ゾーン冗長バックアップ ストレージ (異なるゾーン、同じリージョン) では、バックアップ ファイルはサーバーの可用性ゾーンに格納されて、同じリージョン内の別の可用性ゾーンにレプリケートされます。 このオプションで提供される持続性は、1 年間で 99.9999999999% (9 が 12 個) です。 ゾーン冗長ストレージはゾーン冗長 HA にとって重要であり、データを 1 つのリージョン内に保持する必要がある場合に必要です。
geo 冗長バックアップ ストレージ (異なるリージョン) では、バックアップ ファイルはサーバーのリージョンに格納された後、別の geo ペア リージョンにレプリケートされます。 このオプションで提供される持続性は、1 年間で 99.99999999999999% (9 が 16 個) です。 geo 冗長ストレージは、Azure のペアになっているリージョンでのみサポートされます。
注:Azure Database for MySQL - フレキシブル サーバーでは、プロビジョニングされたストレージ領域の最大 100% までのバックアップ領域を、追加料金なしで利用できます。 追加のストレージは、1 か月ごとに GB 単位で課金されます。 詳しくは、価格に関するドキュメントをご覧ください。
バックアップを用意した後、新しい MySQL フレキシブル サーバーにバックアップを復元できます。 バックアップは、完全バックアップの手動選択、最新の復元ポイントの自動選択、最も速い復元ポイントの自動選択の 3 つの方法で選択できます。 geo 冗長バックアップがある場合は、ペアになったリージョンに (リージョン間で) 復元することもできます。
予定されたダウンタイムとメンテナンス期間
マネージド サーバーを安定した、安全な、最新の状態に保つには、定期的なメンテナンスが必要です。 メンテナンス期間中、サービスは新機能、更新プログラム、パッチのデプロイを受け取ります。 通常、メンテナンス期間は少なくとも 30 日ごとに行われるように予定されますが、重要なセキュリティ パッチは 7 日以内に適用される場合があります。
システムで管理されたスケジュールを選ぶか、Azure サブスクリプション内の MySQL フレキシブル サーバーごとにカスタム スケジュールを定義することができます。
予定メンテナンスの通知は、いくつかの方法のいずれかで受け取ることができます。 次の方法で通知されます。
- 特定のアドレスまたは Azure Resource Manager ロールにメールで送信されます。
- テキスト メッセージ (SMS) 経由で送信されます。
- Azure アプリ通知としてプッシュされます。
- 音声メッセージで配信されます。
カスタム メンテナンス期間
システムが管理するスケジュールの既定では、システムは MySQL フレキシブル サーバーのリージョンのタイム ゾーンで午後 11 時から午前 7 時までの間で 1 時間の期間を選びます。 カスタム スケジュールでは、ユーザーは曜日と 1 時間の時刻を選んで、サーバーのメンテナンス期間を指定できます。
HA サーバーのダウンタイムがほぼゼロのメンテナンス (パブリック プレビュー)
HA が有効なサーバーでは、メンテナンスのダウンタイムを大幅に減らす新機能である、ダウンタイムがほぼゼロのメンテナンスのメリットを得ることができます。 予想されるダウンタイムは 40 から 60 秒です。 非常に高い可用性が必要なアプリケーションでは、ダウンタイムがほぼゼロのメンテナンスが不可欠であり、データベース接続の中断を最小限に抑える必要があります。
メンテナンスを再スケジュールする (パブリック プレビュー)
General Purpose または Business Critical のサービス レベルを使っている場合は、メンテナンスを再スケジュールできます。 Azure portal のメンテナンス セクションで、次の予定メンテナンスを別の日付と時刻に再スケジュールできます。 [今すぐ再スケジュールする] を選んで、オンデマンドでメンテナンスを始めることもできます。