Azure Database for MySQL - フレキシブル サーバーでのバックアップと復元
適用対象:
Azure Database for MySQL - フレキシブル サーバー
Azure Database for MySQL フレキシブル サーバーでは、サーバーのバックアップが自動的に作成されて、リージョン内のローカル冗長ストレージに安全に格納されます。 バックアップを使用すると、サーバーを特定の時点に復元できます。 不慮の破損または削除からデータを保護するバックアップと復元は、ビジネス継続性戦略の最も重要な部分です。
Backup の概要
Azure Database for MySQL フレキシブル サーバーでは、ビジネス クリティカルなデータのバックアップを維持するための柔軟性を高めるため、2 種類のバックアップがサポートされています。
自動化されたバックアップ
Azure Database for MySQL フレキシブル サーバーは、データ ファイルのスナップショット バックアップを取得して、ローカル冗長ストレージに格納します。 また、サーバーによりトランザクション ログのバックアップも実行され、それもローカル冗長ストレージに格納されます。 これらのバックアップを使用すると、サーバーを、バックアップの構成済みリテンション期間内の任意の時点に復元できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、1 から 35 日の範囲でデータベース バックアップを構成できます。 すべてのバックアップの保存データは、AES 256 ビット暗号化を使用して暗号化されます。
オンデマンド バックアップ
Azure Database for MySQL フレキシブル サーバーを使うと、このサービスによって作成される自動バックアップに加えて、運用ワークロードのオンデマンド バックアップをトリガーし、サーバーのバックアップ アイテム保持ポリシーに合わせて格納することもできます。 これらのバックアップを、ポイントインタイム リストアを実行するための最速の復元ポイントとして使用して、復元時間を最大 90% 短縮できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、1 から 35 日の範囲でデータベース バックアップを構成できます。 ポータルから合計 50 個のオンデマンド バックアップをトリガーできます。 すべてのバックアップの保存データは、AES 256 ビット暗号化を使用して暗号化されます。
これらのバックアップ ファイルをエクスポートすることはできません。 バックアップは、Azure Database for MySQL フレキシブル サーバーでの復元操作にのみ使用できます。 MySQL クライアントから mysqldump を使用してデータベースをコピーすることもできます。
バックアップ頻度
フレキシブル サーバーでのバックアップはスナップショット ベースです。 初回のスナップショット バックアップは、サーバーの作成直後にスケジュールされます。 スナップショット バックアップは、毎日 1 回作成されます。 トランザクション ログ バックアップは 5 分ごとに実行されます。 スケジュールされたバックアップが失敗した場合、バックアップ サービスは、バックアップが正常に実行されるまで 20 分ごとにバックアップを試行します。 これらのバックアップ エラーは、サーバー インスタンスでのトランザクションの実稼働負荷が高い場合に発生する可能性があります。
バックアップ冗長オプション
Azure Database for MySQL フレキシブル サーバーでは、計画されたイベントや計画外のイベント (一時的なハードウェア障害、ネットワークの停止や停電、大規模な自然災害など) からデータを保護するため、バックアップの複数のコピーが格納されます。 Azure Database for MySQL フレキシブル サーバーでは、Basic、General Purpose、Business Critical のレベルで、ローカル冗長、ゾーン冗長、geo 冗長の各バックアップ ストレージから柔軟に選択できます。 既定では、Azure Database for MySQL フレキシブル サーバーのバックアップ ストレージは、同一ゾーン高可用性 (HA) のサーバーまたは高可用性構成ではないサーバーの場合はローカル冗長であり、ゾーン冗長 HA 構成のサーバーの場合はゾーン冗長です。
バックアップの冗長性により、障害が発生した場合でもデータベースで可用性と永続性の目標が満たされ、Azure Database for MySQL フレキシブル サーバーでユーザーに 3 つのオプションが示されます。
ローカル冗長バックアップ ストレージ: バックアップがローカル冗長バックアップ ストレージに格納されている場合、バックアップのコピーが同じデータセンターに複数格納されます。 このオプションは、サーバー ラックとドライブの障害からデータを保護します。 また、バックアップ オブジェクトに年間 99.999999999% (イレブン ナイン) 以上の持続性を提供します。 既定では、同一ゾーンの高可用性 (HA) を使用しているサーバー、または高可用性構成のないサーバーのバックアップ ストレージは、ローカル冗長に設定されます。
ゾーン冗長バックアップ ストレージ: バックアップがゾーン冗長バックアップ ストレージに格納されると、その複数のコピーが、サーバーがホストされている可用性ゾーン内に格納されるだけでなく、同じリージョン内の別の可用性ゾーンにもレプリケートされます。 このオプションは、高可用性を必要とするシナリオや、データ所在地の要件を満たすためデータのレプリケーションを国/地域内に制限する目的で利用できます。 また、バックアップ オブジェクトに年間 99.9999999999% (トゥエルブ ナイン) 以上の持続性を提供します。 サーバーの作成時に [ゾーン冗長の高可用性] オプションを選択して、ゾーン冗長バックアップ ストレージを確保することができます。 サーバーの高可用性は作成後に無効にできますが、バックアップ ストレージはゾーン冗長のままになります。
geo 冗長バックアップ ストレージ: バックアップが geo 冗長バックアップ ストレージに格納されると、その複数のコピーが、サーバーがホストされているリージョンに格納されるだけでなく、geo ペア リージョンにもレプリケートされます。 これにより、災害発生時に、より適切な保護が提供され、別のリージョンにサーバーを復元することができます。 また、これにより、99.99999999999999% (16 個の 9) 以上のバックアップ オブジェクトの 1 年間の持続性が提供されます。サーバーの作成時に geo 冗長オプションを有効にして、geo 冗長バックアップ ストレージを確保できます。 さらに、サーバー作成後に、ローカル冗長ストレージから geo 冗長ストレージに移行できます。 Geo 冗長性は、Azure のペアになっているリージョンのいずれかでホストされているサーバーでサポートされます。
Note
ゾーン冗長をサポートするためのゾーン冗長高可用性は、現在、作成時の操作としてのみ表示されます。 現時点では、ゾーン冗長高可用性サーバーの geo 冗長性は、サーバーの作成時にのみ有効または無効にできます。
他のバックアップ ストレージ オプションから geo 冗長バックアップ ストレージへの移行
推奨される次の方法を使用して、既存のバックアップ ストレージを geo 冗長ストレージに移行することができます。
ローカル冗長から geo 冗長バックアップ ストレージへの移行: バックアップ ストレージをローカル冗長ストレージから geo 冗長ストレージに移行するには、Azure portal から [コンピューティングとストレージ] サーバー構成を変更して、ローカル冗長ソース サーバーの geo 冗長性を有効にします。 同一ゾーンの冗長 HA サーバーについても、基になるバックアップ ストレージが同様にローカル冗長であるため、同じやり方で geo 冗長サーバーとして復元することができます。
ゾーン冗長から geo 冗長バックアップ ストレージへの移行: Azure Database for MySQL フレキシブル サーバーでは、サーバーのプロビジョニング後に [コンピューティングとストレージ] の設定を変更して、ゾーン冗長ストレージを geo 冗長ストレージに変換することはできません。 バックアップ ストレージをゾーン冗長ストレージから geo 冗長ストレージに移行するには、2 つのオプションがあります。a) PITR (ポイントインタイム リストア) を使って、必要な構成でサーバーを復元します。 b) 必要な構成で新しいサーバーを作成し、ダンプと復元を使ってデータを移行します。
バックアップ保有期間
バックアップは、サーバーのバックアップ保有期間の設定に基づいて保持されます。 保有期間は 1 から 35 日の範囲で選択でき、既定の保有期間は 7 日です。 Azure portal を使用してバックアップ構成を更新することで、サーバーの作成中またはその後で保有期間を設定することができます。
ポイントインタイム リストアは使用可能なバックアップに基づいているため、その操作を現在からどのくらい遡って実行できるかは、バックアップの保有期間によって管理されます。 バックアップの保有期間は、復元の観点から回復期間として扱うこともできます。 バックアップ保有期間内の特定の時点に復旧するために必要なすべてのバックアップは、バックアップ ストレージに保持されます。 たとえば、バックアップの保有期間が 7 日に設定されている場合、回復期間は過去 7 日間と見なされます。 このシナリオでは、過去 7 日間のサーバーを復元するために必要なすべてのバックアップが保持されます。 バックアップ保有期間が 7 日の場合、データベース スナップショットとトランザクション ログ バックアップは、過去 8 日間 (期間の 1 日前まで) について格納されます。
バックアップ ストレージのコスト
Azure Database for MySQL フレキシブル サーバーは、プロビジョニングされているサーバー ストレージの 100% まで、バックアップ ストレージとして追加コストなしで提供します。 バックアップ ストレージを追加で使用した場合は、1 か月ごとに GB 単位で請求されます。 たとえば、サーバーに 250 GB のストレージをプロビジョニングした場合は、250 GB のストレージを追加料金なしでサーバーのバックアップに利用できます。 毎日のバックアップ使用量が 25 GB の場合は、無料バックアップ ストレージを最大 10 日間使用できます。 250 GB を超えてバックアップに使用されているストレージについては、価格モデルに従って請求されます。
Azure portal で使用可能な Azure Monitor の使用されたバックアップ ストレージ メトリックを使用して、サーバーによって使用されるバックアップ ストレージを監視できます。 使用済みバックアップ ストレージ メトリックは、サーバーに設定されているバックアップ保有期間に基づいて保持されるすべてのデータベース バックアップとログ バックアップによって使用されたストレージの合計を表します。 サーバーで大量のトランザクション アクティビティが発生すると、データベースの合計サイズに関係なく、バックアップ ストレージの使用量が増加する可能性があります。 Geo 冗長サーバーに使用されるバックアップ ストレージは、ローカル冗長サーバーの 2 倍になります。
バックアップ ストレージ コストを制御する主な方法は、適切なバックアップ保有期間を設定することです。 保有期間は 1 日から 35 日の範囲で選択できます。
重要
ゾーン冗長高可用性構成で構成されたデータベース サーバーからのバックアップは、スナップショット バックアップでのオーバーヘッドが最小限に抑えられるため、プライマリ データベース サーバーから行われます。
使用可能な完全バックアップを表示する
Azure portalの [バックアップと復元] ブレードには、あらゆる時点で使用可能な完全バックアップの完全な一覧が表示されます。 これには、自動バックアップとオンデマンド バックアップが含まれます。 このブレードを使用すると、サーバーの保有期間中に使用可能なすべての完全バックアップの完了タイムスタンプを表示し、これらの完全バックアップを使用して復元操作を実行できます。 使用可能なバックアップの一覧には、保有期間中のすべての完全バックアップ、正常に完了したことを示すタイムスタンプ、バックアップの保持期間を示すタイムスタンプ、復元アクションが含まれます。
復元
Azure Database for MySQL フレキシブル サーバーで復元を実行すると、元のサーバーのバックアップから新しいサーバーが作成されます。 使用できる復元には 2 つの種類があります。
- ポイントインタイム リストア: いずれのバックアップ冗長オプションでも使用でき、元のサーバーと同じリージョンに新しいサーバーが作成されます。
- geo 復元: geo 冗長ストレージとしてサーバーを構成した場合にのみ利用でき、geo ペアのリージョンまたはフレキシブル サーバーが利用できる他の Azure 対応リージョンに、サーバーを復元できます。
サーバーの復旧にかかる推定時間は、次のいくつかの要因によって異なります。
- データベースのサイズ
- 関連するトランザクション ログ数
- 復元時点に復旧するために再生の必要があるアクティビティ量
- 別のリージョンへの復元の場合は、ネットワーク帯域幅
- ターゲット リージョンで処理される、同時実行される復元要求の数
- データベース内のテーブルに主キーが存在するかどうか。 高速復旧を行うには、データベース内のすべてのテーブルに主キーを追加することを検討してください。
Note
高可用性が有効になっているサーバーは、ポイントインタイム リストアと geo リストアのどちらの場合も、復元後に非 HA (高可用性が無効) になります。
ポイントインタイム リストア
Azure Database for MySQL フレキシブル サーバーでポイントインタイム リストアを実行すると、ソース サーバーと同じリージョンに、フレキシブル サーバーのバックアップから新しいサーバーが作成されます。 コンピューティング レベル、仮想コア数、ストレージ サイズ、バックアップ保有期間、バックアップ冗長オプションについては、元のサーバーの構成で作成されます。 また、仮想ネットワークやファイアウォールなどのタグと設定は、ソース サーバーから継承されます。 復元されたサーバーのコンピューティング レベルとストレージ レベル、構成、セキュリティの設定は、復元が完了した後で変更できます。
Note
復元操作の後で既定値にリセットされる (そして、プライマリ サーバーからコピーで上書きされない) サーバー パラメーターが 2 つあります
- time_zone - この値は、既定値 SYSTEM に設定されます
- event_scheduler - 復元されたサーバーでは event_scheduler は OFF に設定されます
ポイントインタイム リストアは複数のシナリオで役に立ちます。 一般的なユース ケースとしては、次のようなものがあります。
- ユーザーがデータベース内のデータを誤って削除した場合
- ユーザーが重要なテーブルまたはデータベースを削除する
- ユーザー アプリケーションの欠陥のため、正しいデータが不適切なデータで誤って上書きされる。
最新の復元ポイント、カスタム復元ポイント、Azure portal を介した最速の復元ポイント (完全バックアップを使用した復元) から選択できます。
- 最新の復元ポイント: 最新の復元ポイントのオプションは、復元操作がトリガーされたときのタイムスタンプにサーバーを復元するために役立ちます。 このオプションは、サーバーを最も更新された状態にすばやく復元するのに役立ちます。
- カスタム復元ポイント: このオプションを使うと、このサーバーに定義されている保持期間内の特定の時点を選択できます。 このオプションは、ユーザー エラーから復旧するために、サーバーを正確な時点まで復元する場合に便利です。
- 最速の復元ポイント: このオプションを使うと、ユーザーは、サーバーに対して定義された保持期間内の特定の日に、可能な限り最速の時間でサーバーを復元できます。 最速の復元は、完全バックアップが完了した時点の復元ポイントを選択することで可能です。 この復元操作では、スナップショットの完全バックアップが復元されるだけで、高速になるログの復元や復旧は保証されません。 復元操作を正常に実行するには、最も古い復元ポイントを超える完全バックアップ タイムスタンプを選択することをお勧めします。
復旧にかかる推定時間は、データベースのサイズ、トランザクション ログのバックアップ サイズ、SKU のコンピューティング サイズ、復元の時刻など、いくつかの要因によって異なります。 トランザクション ログの復旧は、復元プロセスの中で最も時間がかかる部分です。 スナップショット バックアップのスケジュールに近い復元時刻を選択すると、トランザクション ログの適用が最小限になるため、復元操作の速度が速くなります。 サーバーの復旧時間を正確に見積もるには、環境に固有の変数が多すぎるため、実際の環境でテストすることを強くお勧めします。
重要
ゾーン冗長高可用性で構成された Azure Database for MySQL フレキシブル サーバーのインスタンスを復元する場合、復元されたサーバーは、プライマリ サーバーと同じリージョンおよびゾーン内に構成され、非 HA モードの単一サーバーとしてデプロイされます。 フレキシブル サーバーに対するゾーン冗長高可用性に関するページを参照してください。
重要
削除された Azure Database for MySQL フレキシブル サーバー リソースは、サーバーを削除した時点から 5 日以内であれば復旧できます。 削除されたサーバーを復元する方法の詳細なガイドについては、文書化されている手順を参照してください。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを利用できます。
geo リストア
サービスを利用できる geo ペア リージョン (geo 冗長バックアップ用にサーバーを構成している場合)、または Azure Database for MySQL フレキシブル サーバーを利用できる他の Azure サポート対象リージョンに、サーバーを復元できます。 ペアになっていない Azure サポート対象リージョンのどれか (Brazil South、USGov Virginia、West US 3) 以外) に復元する機能は "ユニバーサル geo リストア" と呼ばれます。
geo リストアは、サーバーがホストされているリージョンでのインシデントが原因でサーバーが利用できない場合の既定の復旧オプションです。 リージョン内の大規模なインシデントにより、データベース アプリケーションが使用できなくなった場合、geo 冗長バックアップから他の任意のリージョン内のサーバーに、サーバーを復元できます。 geo リストアでは、サーバーの最新のバックアップが利用されます。 バックアップが取得される時刻と、別のリージョンにそのバックアップがレプリケートされる時刻には時間差があります。 この時間差は最大 1 時間なので、障害が発生した場合、最大 1 時間分のデータが失われる可能性があります。
Azure CLI を利用して、停止されたサーバーで geo リストアを実行することもできます。 Azure CLI を使ったサーバーの geo 復元について詳しくは、Azure CLI での Azure Database for MySQL フレキシブル サーバーの復元に関する記事をご覧ください。
復旧の推定所要時間は、データベースのサイズ、トランザクション ログのサイズ、ネットワーク帯域幅、同じリージョン内で同時に復旧するデータベースの合計数など、複数の要因によって異なります。
Note
ゾーン冗長高可用性で構成された Azure Database for MySQL フレキシブル サーバーのインスタンスを geo 復元する場合、復元されたサーバーは、geo ペア リージョンのプライマリ サーバーと同じゾーン内に構成され、非 HA モードで単一の Azure Database for MySQL フレキシブル サーバー インスタンスとしてデプロイされます。 Azure Database for MySQL フレキシブル サーバーのゾーン冗長高可用性に関する記事をご覧ください。
重要
プライマリ リージョンがダウンすると、プライマリ リージョンでストレージをプロビジョニングできないため、対応する geo ペア リージョン内に geo 冗長サーバーを作成できません。 geo ペア リージョンで geo 冗長サーバーをプロビジョニングするには、プライマリ リージョンが稼働するまで待機する必要があります。 プライマリ リージョンがダウンしていても、ソース サーバーを geo ペア リージョンに geo リストアすることはできます。それには、ポータルでの復元エクスペリエンスで、[コンピューティングとストレージ] の [サーバーの構成] 設定にある geo 冗長オプションを無効にし、ローカル冗長サーバーとして復元してビジネス継続性を確保します。
復元後のタスクの実行
最新の復元ポイントまたはカスタム復元ポイントのいずれかの復旧メカニズムで復元した後、ユーザーとアプリケーションを元に戻して実行するには、次のタスクを実行する必要があります。
- 元のサーバーを新しいサーバーで置き換える場合は、クライアントとクライアント アプリケーションを新しいサーバーにリダイレクトします。
- ユーザーが接続できるように、サーバー レベルの適切なファイアウォール規則と仮想ネットワーク規則が適用されていることを確認します。
- 適切なログインとデータベース レベルのアクセス許可が指定されていることを確認します。
- 必要に応じて、アラートを構成します。
長期保有 (プレビュー)
Azure Backup サービスと Azure Database for MySQL フレキシブル サーバー サービスでは、最大 10 年間バックアップを保持する Azure Database for MySQL フレキシブル サーバー インスタンス用のエンタープライズ クラスの長期的なバックアップ ソリューションが構築されています。 長期保有は、独立して使うことも、Azure Database for MySQL フレキシブル サーバーによって提供される自動バックアップ ソリューションに加えて使うこともでき、最大 35 日間のデータ保持が提供されます。 自動バックアップは、特に最新のバックアップから復元する場合に、運用復旧に適したスナップショット バックアップです。 長期的にバックアップを作成すると、コンプライアンスのニーズと監査のニーズに役立ちます。 このソリューションには、長期保有に加えて、次の機能が用意されています:
- お客様が制御するスケジュールされたバックアップとオンデマンドのバックアップ
- バックアップ センターと呼ばれる 1 つのガラスのペインから、サーバー、リソース グループ、場所、サブスクリプション、テナント間のすべてのバックアップ関連の操作とジョブを管理および監視します。
- バックアップは、個別のセキュリティ ドメインと障害ドメインに保存されます。 ソース サーバーまたはサブスクリプションが侵害された場合、Backupコンテナー (Azure Backup マネージド ストレージ アカウント) でバックアップは安全なままです。
制限と考慮事項
- プレビューでは、LTR 復元は現在、ストレージ アカウントへの RestoreasFiles として使用できます。 RestoreasServer 機能は、今後追加される予定です。
- 現在、Azure CLI を使用した LTR の作成と管理はサポートされていません。
長期的なバックアップの実行の詳細については、「攻略ガイド」を参照してください
オンデマンド バックアップとエクスポート (プレビュー)
Azure Database for MySQL フレキシブル サーバーでは、サーバーのオンデマンドの物理バックアップをトリガーし、それを Azure ストレージ アカウント (Azure BLOB ストレージ) にエクスポートできるようになりました。 エクスポートしたバックアップは、データの復旧、移行、冗長性に使用できます。 これらのエクスポートされた物理バックアップ ファイルを使用してオンプレミスの MySQL サーバーに復元し、組織の監査/コンプライアンス/アーカイブのニーズを満たすことができます。 この機能は現在パブリック プレビュー段階であり、パブリック クラウド リージョンでのみ使用できます。
エクスポート バックアップの詳細については、攻略ガイドを参照してください
よく寄せられる質問 (FAQ)
バックアップに関連する質問
サーバーをバックアップするにはどうすればよいですか?
既定では、Azure Database for MySQL フレキシブル サーバーによって、サーバー全体 (作成されたすべてのデータベースを含む) の自動バックアップが有効になり、既定の保持期間は 7 日です。 オンデマンド バックアップ機能を使用して手動バックアップをトリガーすることもできます。 バックアップを手動で作成する別の方法は、コミュニティ ツールを使用することです。たとえば、mysqldump (ドキュメントはこちら)、mydumper (ドキュメントはこちら) などを使用します。 Azure Database for MySQL フレキシブル サーバーのインスタンスを BLOB ストレージにバックアップしたい場合は、技術コミュニティで BLOB ストレージへの Azure Database for MySQL フレキシブル サーバーのバックアップに関するブログをご覧ください。
自動バックアップが長期間保有されるように構成できますか。
いいえ。現在サポートされているのは、最大 35 日間の自動バックアップ保有のみです。 手動バックアップを作成して、それを長期保有の要件に対して使用することができます。
サーバーのバックアップ ウィンドウとは何ですか? カスタマイズできますか?
初回のスナップショット バックアップは、サーバーの作成直後にスケジュールされます。 スナップショット バックアップは、毎日 1 回作成されます。 トランザクション ログ バックアップは 5 分ごとに実行されます。 バックアップ期間は本質的に Azure によって管理されており、カスタマイズできません。
バックアップは暗号化されますか?
Azure Database for MySQL フレキシブル サーバーのデータ、バックアップ、クエリ実行中に作成される一時ファイルはすべて、AES 256 ビット暗号化を使って暗号化されます。 ストレージの暗号化は常にオンになっており、無効にできません。
単一または少数のデータベースを復元できますか。
単一または少数のデータベースまたはテーブルの復元はサポートされていません。 特定のデータベースを復元する場合は、ポイントインタイム リストアを実行してから、必要なテーブルまたはデータベースを抽出します。
バックアップの時間帯にサーバーを使用できますか。
はい。 バックアップはオンライン操作であり、スナップショットベースです。 スナップショット操作には数秒しかかからず、運用ワークロードに影響しないため、サーバーの高可用性が確保されます。
サーバーのメンテナンス期間を設定するとき、バックアップ期間を考慮する必要がありますか?
いいえ。バックアップは管理サービスの一部として内部的にトリガーされ、管理されたメンテナンス期間には関係しません。
自動バックアップはどこに格納され、その保有期間はどのように管理できますか。
Azure Database for MySQL フレキシブル サーバーでは、サーバーのバックアップが自動的に作成されて、ユーザーが構成したローカル冗長ストレージまたは geo 冗長ストレージに保存されます。 これらのバックアップ ファイルをエクスポートすることはできません。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、1 から 35 日の範囲でデータベース バックアップを構成できます。
バックアップを検証するにはどうすればよいですか。
正常に完了したバックアップの可用性を検証する最善の方法は、[バックアップと復元] ブレードで、保有期間中に作成された完全な自動バックアップを表示する方法です。 バックアップが失敗した場合、そのバックアップは使用可能なバックアップの一覧に表示されず、バックアップ サービスは、バックアップが正常に作成されるまで 20 分ごとにバックアップを試みます。 これらのバックアップ エラーは、サーバーでのトランザクションの実稼働負荷が高い場合に発生します。
バックアップの使用量はどこで確認できますか?
Azure portal の [監視] タブの [メトリック] セクションで見つかる使用済みバックアップ ストレージ メトリックは、バックアップの合計使用量を監視するのに役立ちます。
サーバーを削除した場合、バックアップはどうなりますか?
サーバーを削除すると、そのサーバーに属するバックアップもすべて削除され、復旧できなくなります。 管理者は、デプロイ後のサーバー リソースを誤削除や予期しない変更から保護するため、管理ロックを使用できます。
サーバーを復元すると、バックアップはどうなりますか?
サーバーを復元すると、常に、元のサーバーのバックアップを使って復元されたまったく新しいサーバーが作成されます。 元のサーバーからの古いバックアップは、新しく復元されたサーバーにコピーされず、元のサーバーに残ります。 ただし、新しく作成されたサーバーの場合、最初のスナップショット バックアップはサーバー作成直後にスケジュールされ、サービスによって毎日自動的にバックアップが作成されて、構成されたサーバーの保持期間に従って保存されます。
バックアップの使用に対しては、どのように課金および請求されますか?
Azure Database for MySQL フレキシブル サーバーでは、バックアップ ストレージとしてプロビジョニングされているサーバー ストレージの 100% まで、追加コストなしで提供されます。 それを超えて使われたバックアップ ストレージは、価格モデルに従って、1 か月ごとに GB 単位で課金されます。 また、バックアップ ストレージの課金は、バックアップ ストレージの合計使用量に直接影響するサーバーでのトランザクション アクティビティとは別に、選択されたバックアップ保持期間と選択されたバックアップ冗長性オプションによっても管理されます。
停止したサーバーのバックアップはどのように保有されますか?
停止したサーバーに対して、新しいバックアップは実行されません。 サーバーを停止した時点でのすべての古いバックアップ (保持期間内のもの) は、サーバーが再起動されるまで保持されます。その後、アクティブなサーバーのバックアップの保持は、そのバックアップ保持期間によって管理されます。
停止しているサーバーのバックアップについては、どのように請求されますか。
サーバー インスタンスが停止している間は、プロビジョニングされたストレージ (プロビジョニングされた IOPS を含む) とバックアップ ストレージ (指定した保持期間内の格納されているバックアップ) に対して課金されます。 無料バックアップ ストレージは、プロビジョニングしたデータベースのサイズに制限され、アクティブなサーバーにのみ適用されます。
バックアップ データはどのように保護されますか?
Azure Database for MySQL フレキシブル サーバーは、構成された保持期間の回復ポイントが失われる可能性のある操作をすべてブロックすることで、バックアップ データを保護します。 保持期間中に作成されたバックアップは、復元の目的でのみ読み取ることができ、保持期間後に削除されます。 また、Azure Database for MySQL フレキシブル サーバーのすべてのバックアップは、格納データ用の AES 256 ビット暗号化を使って保存時に暗号化されます。
ポイントインタイム リストア (PITR) 操作は IOPS の使用量にどのように影響しますか?
Azure Database for MySQL - フレキシブル サーバーでの PITR 操作の間に、新しいサーバーが作成されて、ソース サーバーのストレージから新しいサーバーのストレージにデータがコピーされます。 このプロセスにより、ソース サーバーでの IOPS 使用量が増えます。 IOPS 使用量のこの増加は通常の出来事であり、ソース サーバーまたは PITR 操作に関する問題を示すものではありません。 PITR 操作が完了すると、ソース サーバーでの IOPS 使用量は通常のレベルに戻ります。
復元に関連する質問
サーバーを復元するにはどうすればよいですか? Azure portal ではすべてのサーバーについてポイントインタイム リストアがサポートされ、ユーザーは最新またはカスタムの復元ポイントに復元できます。 mysqldump/myDumper によって作成されたバックアップからサーバーを手動で復元するには、「myLoader を使用してデータベースを復元する」をご覧ください。
復元に長時間かかるのはなぜですか。
サーバーの復旧にかかる推定時間は、次のいくつかの要因によって異なります。
- データベースのサイズ。 復旧プロセスの一環として、データベースを最新の物理バックアップからハイドレートする必要があるため、復旧にかかる時間はデータベースのサイズに比例します。
- 復旧のために再生する必要があるトランザクション アクティビティのアクティブな部分。 最後に成功したチェックポイント以降の追加のトランザクション アクティビティによっては、復旧に時間がかかる場合があります。
- 別のリージョンへの復元の場合は、ネットワーク帯域幅。
- ターゲット リージョンで処理される、同時実行される復元要求の数
- データベース内のテーブルに主キーが存在するかどうか。 復旧を速くするには、データベース内のすべてのテーブルに主キーを追加することを検討してください。
セッション レベルのデータベース変数を変更すると、復元に影響しますか?
セッション レベルの変数を変更し、MySQL クライアント セッションで DML ステートメントを実行すると、PITR (ポイントインタイム リストア) 操作に影響を与える可能性があります。これらの変更は、バックアップと復元の操作に使われるバイナリ ログに記録されないためです。 たとえば、foreign_key_checks はこのようなセッション レベルの変数の 1 つであり、外部キー制約に違反する DML ステートメントを実行するために無効にすると、PITR (ポイントインタイム リストア) エラーが発生します。 このようなシナリオの唯一の回避策は、foreign_key_checks が無効にされた日時より前の PITR 日時を選ぶことです。 PITR 操作が成功するようにセッション変数を変更しないことをお勧めします。
次のステップ
- ビジネス継続性について確認する
- ゾーン冗長による高可用性について確認する
- バックアップと復旧について確認する
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示