Azure Database for MariaDB でのビジネス継続性の概要
重要
Azure Database for MariaDB は、提供終了予定です。 Azure Database for MySQL に移行することを強くお勧めします。 Azure Database for MySQL への移行の詳細については、「Azure Database for MariaDB の動作」を参照してください。
この記事では、Azure Database for MariaDB に用意されているビジネス継続性とディザスター リカバリーの機能について説明します。 また、データ損失につながる、またはデータベースやアプリケーションを使用不能状態に追い込む破壊的なイベントから復旧するためのオプションについて説明します。 ユーザー エラーまたはアプリケーション エラーがデータの整合性に影響を与えた場合、Azure リージョンで障害が発生した場合、またはアプリケーションにメインテナントが必要な場合の対応について説明します。
ビジネス継続性のための機能
ビジネス継続性計画を策定するときは、次の内容を理解する必要があります。
- 目標復旧時間 (RTO): 中断を伴うイベントの後にアプリケーションが完全に復旧するまでの最大許容時間。
- 目標復旧ポイント (RPO): 中断を伴うイベントの後に回復するときに、アプリケーションが損失を許容できる最新のデータ更新の最大量 (時間間隔)。
Azure Database for MariaDB には、geo 冗長バックアップを含むビジネス継続性とディザスター リカバリー機能が用意されており、geo リストアを開始したり、別のリージョンに読み取りレプリカをデプロイしたりできます。 それぞれ、復旧時間と潜在的なデータ損失に関する特性が異なります。
geo リストアを使用すると、Azure Database for MariaDB は、別のリージョンからレプリケートされたバックアップ データを使用して新しいサーバーを作成します。 復元と復旧の全体的な時間は、データベースのサイズと回復するログ データの量によって異なります。 サーバーの確立にかかる全体的な時間は、数分から数時間に範囲で変化します。
読み取りレプリカでは、プライマリ データベースからのトランザクション ログがレプリカに非同期的にストリーミングされます。 ゾーン レベルまたはリージョン レベルの障害が原因でプライマリ データベースが停止した場合、レプリカにフェールオーバーすると、RTO が短くなり、データ損失が減少します。
Note
プライマリ データベースとレプリカの間の遅延は、サイト間の待機時間、送信されるデータの量、および (最も重要な) プライマリ サーバーの書き込みワークロードによって異なります。 書き込みワークロードが多いと、大幅な遅延が発生する可能性があります。
読み取りレプリカに使用されるレプリケーションの非同期的な性質のため、読み取りレプリカを高可用性ソリューションと見なさないでください。 ラグが大きいほど、RTO と RPO が高くなる可能性があります。 読み取りレプリカは、ピーク時とオフピーク時にラグがメイン小さいワークロードに対してのみ、高可用性の代替手段として機能できます。 それ以外の場合、読み取りレプリカは、読み取り負荷の高いワークロードとディザスター リカバリーシナリオ用の真の読み取りスケールを目的としています。
次の表は、一般的なワークロード シナリオでの RTO と RPO を比較したものです。
| 機能 | Basic | 汎用 | メモリの最適化 |
|---|---|---|---|
| バックアップからのポイントインタイム リストア | リテンション期間内の任意の復元ポイント RTO は異なります RPO が 15 分未満 |
リテンション期間内の任意の復元ポイント RTO は異なります RPO が 15 分未満 |
リテンション期間内の任意の復元ポイント RTO は異なります RPO が 15 分未満 |
| Geo レプリケーション バックアップからの geo リストア | サポートされていません | RTO は異なります RPO が 24 時間を超えています |
RTO は異なります RPO が 24 時間を超えています |
| 読み取りレプリカ | RTO は分です RPO が 5 分未満 |
RTO は分です RPO が 5 分未満 |
RTO は分です RPO が 5 分未満 |
サイト間の待機時間、送信するデータの量、プライマリ データベースの書き込みワークロードなどの要因に応じて、RTO と RPO がはるかに高 くなる場合があります。
ユーザーまたはアプリケーション エラー後のサーバーの回復
サービスのバックアップを使って、さまざまな破壊的イベントからサーバーを復旧できます。 たとえば、ユーザーが誤って一部のデータを削除したり、重要なテーブルを誤って削除したり、データベース全体を削除したりする場合があります。 アプリケーションの欠陥が原因で、アプリケーションが誤って適切なデータを不適切なデータで上書きする可能性があります。
ポイントインタイム リストアを実行して、正常であることがわかっている時点のサーバーのコピーを作成できます。 この時点は、サーバー用に構成したバックアップ保有期間内である必要があります。 データが新しいサーバーに復元されたら、元のサーバーを新しく復元されたサーバーに置き換えるか、復元されたサーバーから元のサーバーに必要なデータをコピーできます。
重要
削除されたサーバーは、削除から 5 日以内 にのみ復元できます。 5 日後にバックアップが削除されます。 データベース バックアップにアクセスして復元できるのは、サーバーをホストする Azure サブスクリプションからのみです。 削除されたサーバーを復元するには、文書化されている手順を参照してください。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを使用できます。
Azure リージョンのデータセンターの停止からの復旧
まれですが、Azure データセンターで障害が発生する可能性があります。 停止が発生すると、数分しか続かない可能性があるが、何時間も続く可能性があるビジネスの中断が発生します。
1 つのオプションは、データセンターの停止が終わったら、サーバーがオンラインに戻るのを待つ方法です。 データセンターで障害が発生した場合、停止がいつまで続くかわかりません。 そのため、このオプションは、しばらくの間サーバーをオフラインにできるアプリケーション (開発環境など) に対してのみ機能します。
geo リストア
geo リストア機能は、geo 冗長バックアップを使用してサーバーを復元します。 バックアップは、サーバーのペアになっているリージョンでホストされます。 これらのバックアップは、サーバーがホストされているリージョンがオフラインの場合でもアクセスできます。 これらのバックアップから他の任意のリージョンに復元し、サーバーをオンラインに戻すことができます。 geo リストアの詳細については、バックアップと復元の 概念に関する記事を参照してください。
重要
geo リストアは、geo 冗長バックアップ ストレージを使用してサーバーをプロビジョニングした場合にのみ可能です。 既存のサーバーのローカル冗長バックアップから geo 冗長バックアップに切り替える場合は、mysqldump を使用して既存のサーバーのバックアップを生成する必要があります。 次に、geo 冗長バックアップで構成された新しく作成されたサーバーに復元します。
リージョンにまたがる読み取りレプリカ
リージョン間の読み取りレプリカを使用して、ビジネス継続性とディザスター リカバリーの計画を強化できます。 読み取りレプリカは、バイナリ ログ用の MySQL のレプリケーション テクノロジによって非同期的に更新されます。 読み取りレプリカ、使用可能なリージョン、および読み取りレプリカの 概念に関する記事でフェールオーバーする方法について説明します。
よく寄せられる質問
Azure Database for MariaDB は顧客データをどこに格納しますか?
既定では、Azure Database for MariaDB は、顧客データをデプロイ先のリージョンから移動したり、保存したりしません。 ただし、必要に応じて、geo 冗長バックアップを有効にするか、別のリージョンにデータを格納するためのリージョン間読み取りレプリカを作成することもできます。
次のステップ
- Azure Database for MariaDB での自動バックアップの詳細を確認する。
- Azure portal または Azure CLI を使用して復元する方法について説明します。
- Azure Database for MariaDB の読み取りレプリカについて確認する。