次の方法で共有

Azure Database for MySQL - シングル サーバーでのビジネス継続性の概要

  • [アーティクル]

適用対象: Azure Database for MySQL - 単一サーバー

重要

Azure Database for MySQL シングル サーバーは廃止パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、Azure Database for MySQL シングル サーバーの現状に関するページを参照してください

この記事では、Azure Database for MySQL に用意されているビジネス継続性とディザスター リカバリーの機能について説明します。 また、データ損失につながる、またはデータベースやアプリケーションを使用不能状態に追い込む破壊的なイベントから復旧するためのオプションについて説明します。 ユーザーまたはアプリケーション エラーがデータ整合性に影響を及ぼすとき、Azure リージョンでシステム停止が発生したとき、あるいはアプリケーションにメンテナンスが必要なときの対処方法について説明します。

ビジネス継続性を提供するときに使用できる機能

ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解する必要があります。これが目標復旧時間 (RTO) です。 さらに、破壊的なイベントの発生後、復旧中にアプリケーションが損失を許容できる最大データ更新 (期間) 量についても理解しなければなりません。これは目標復旧時点 (RPO) です。

Azure Database for MySQL 単一サーバーでは、geo リストアを開始する機能を備えた geo 冗長バックアップおよび別のリージョンへの読み取りレプリカのデプロイを含む、ビジネス継続性およびディザスター リカバリー機能が提供されています。 それぞれ、復旧時間と潜在的なデータ損失に関する特性が異なります。 geo リストア機能を使用すると、別のリージョンからレプリケートされたバックアップ データを使用して新しいサーバーが作成されます。 復元と復旧にかかる全体的な時間は、データベースのサイズと、復旧するログの量によって異なります。 サーバーの確立にかかる全体的な時間は、数分から数時間に範囲で変化します。 読み取りレプリカを使用すると、プライマリからのトランザクション ログがレプリカに非同期にストリーミングされます。 ゾーン レベルまたはリージョン レベルの障害が原因でプライマリ データベースが停止した場合、レプリカにフェールオーバーすると RTO が短縮され、データ損失が減少します。

Note

プライマリとレプリカの間の遅延は、サイト間の待機時間、転送されるデータの量、および最も重要な要素としてプライマリ サーバーの書き込みワークロードによって異なります。 書き込み負荷の高いワークロードでは、大幅な遅延が発生する可能性があります。

読み取りレプリカに使用されるレプリケーションには非同期の性質があるため、それらは高可用性 (HA) ソリューションとして考慮すべきではありません。これは、遅延が大きいほど RTO および RPO が高くなるためです。 ワークロードのピーク時とピーク時以外の期間を通して遅延が小さいワークロードについてのみ、読み取りレプリカは HA の代替として機能します。 それ以外の場合、読み取りレプリカは、読み取り負荷の高いワークロードおよび DR (ディザスター リカバリー) シナリオに対する真の読み取りスケールを目的としています。

次の表は、一般的なワークロード シナリオでの RTO と RPO を比較したものです。

機能 Basic 汎用 メモリの最適化
バックアップからのポイントインタイム リストア リテンション期間内の任意の復元ポイント
RTO - 変動
RPO < 15 分		 リテンション期間内の任意の復元ポイント
RTO - 変動
RPO < 15 分		 リテンション期間内の任意の復元ポイント
RTO - 変動
RPO < 15 分
Geo レプリケーション バックアップからの geo リストア サポートされていません RTO - 変動
RPO < 1 時間		 RTO - 変動
RPO < 1 時間
読み取りレプリカ RTO - 分単位*
RPO < 5 分*		 RTO - 分単位*
RPO < 5 分*		 RTO - 分単位*
RPO < 5 分*

* RTO と RPO は、場合により、サイト間の待機時間、転送されるデータの量、および重要な要素としてプライマリ データベースの書き込みワークロードなどのさまざまな要因によって大幅に高くなることがあります。

ユーザーまたはアプリケーション エラーの後でサーバーを復旧する

サービスのバックアップを使って、さまざまな破壊的イベントからサーバーを復旧できます。 一部のデータ、重要なテーブル、そしてデータベース全体さえも、うっかり削除してしまう場合があります。 アプリケーションの欠陥などにより、正しいデータが不良データによって誤って上書きされることもあります。

ポイントインタイム リストアを実行して、正常であることがわかっている時点のサーバーのコピーを作成できます。 この時点は、サーバーに対して構成されているバックアップ リテンション期間内でなければなりません。 新しいサーバーにデータを復元した後は、元のサーバーを新しく復元したサーバーに置き換えたり、復元したサーバーから元のサーバーに必要なデータをコピーしたりできます。

重要

削除されたサーバーを復元できるのは、削除から 5 日以内のみです。その後、バックアップが削除されます。 データベースのバックアップは、サーバーをホストしている Azure サブスクリプションからのみアクセスおよび復元できます。 削除されたサーバーを復元するには、文書化されている手順を参照してください。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを利用できます。

Azure リージョンのデータ センターの停止から復旧する

まれではありますが、Azure データ センターが停止することもあります。 停止が発生すると、ビジネスが中断します。この中断はわずか数分で解消されることもありますが、数時間に及ぶ場合もあります。

オプションの 1 つは、データ センターの停止が終了し、サーバーがオンラインに戻るのを待つことです。 開発環境など、サーバーがしばらくオフラインになっていてもかまわないアプリケーションの場合はこの方法が使えます。 データ センターが停止したときは、復旧までの時間を予測できないため、このオプションはしばらくサーバーが必要ない場合にのみ有効です。

geo リストア

geo リストア機能では、geo 冗長バックアップを使用してサーバーを復元します。 バックアップは、サーバーのペアになっているリージョンでホストされます。 これらのバックアップは、サーバーがホストされているリージョンがオフラインのときでもアクセスできます。 これらのバックアップから他の任意のリージョンに復元し、サーバーをオンラインに戻すことができます。 geo リストアの詳細については、バックアップと復元の概念に関する記事を参照してください。

重要

geo リストアは、geo 冗長バックアップ ストレージでサーバーをプロビジョニングした場合にのみ可能です。 既存のサーバーに対してローカル冗長を geo 冗長バックアップに切り替える場合は、既存のサーバーの mysqldump を使用してダンプを取得し、geo 冗長バックアップで構成された新しく作成したサーバーに復元する必要があります。

リージョンにまたがる読み取りレプリカ

リージョンにまたがる読み取りレプリカを使用すると、事業継続とディザスター リカバリーの計画を強化できます。 読み取りレプリカは、MySQL のバイナリ ログ レプリケーション テクノロジを使用して非同期的に更新されます。 読み取りレプリカ、利用可能なリージョン、フェールオーバーする方法については、読み取りレプリカの概念に関する記事を参照してください。

よく寄せられる質問

Azure Database for MySQL は顧客データをどこに格納しますか?

既定では、Azure Database for MySQL によって、デプロイされているリージョン外に顧客データが移動または格納されることはありません。 ただし、顧客は必要に応じて、地理冗長バックアップを有効にするか、別のリージョンにデータを格納するためのクロスリージョン読み取りレプリカを作成することを選択できます。

次のステップ