Azure Database for MySQL フレキシブル サーバーでのバックアップと復元

適用対象: Azure Database for MySQL - フレキシブル サーバー

Azure Database for MySQL フレキシブル サーバーを使用すると、サーバーのバックアップが自動的に作成されて、リージョン内のローカル冗長ストレージに安全に格納されます。 バックアップを使用すると、サーバーを特定の時点に復元できます。 不慮の破損または削除からデータを保護するバックアップと復元は、ビジネス継続性戦略の最も重要な部分です。

Backup の概要

フレキシブル サーバーは、ビジネス クリティカルなデータのバックアップを維持するための柔軟性を高めるために、2 種類のバックアップをサポートしています。

自動バックアップ

フレキシブル サーバーを使用すると、データ ファイルのスナップショット バックアップが取得されて、ローカル冗長ストレージに格納されます。 また、サーバーによりトランザクション ログのバックアップも実行され、それもローカル冗長ストレージに格納されます。 これらのバックアップを使用すると、サーバーを、バックアップの構成済みリテンション期間内の任意の時点に復元できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、1 から 35 日の範囲でデータベース バックアップを構成できます。 すべてのバックアップの保存データは、AES 256 ビット暗号化を使用して暗号化されます。

オンデマンド バックアップ

フレキシブル サーバーを使用すると、お客様は、Azure Database for MySQL フレキシブル サービスによって作成された自動バックアップに加えて、運用ワークロードのオンデマンド バックアップをトリガーし、サーバーのバックアップ アイテム保持ポリシーに合わせて格納することもできます。 これらのバックアップを、ポイントインタイム リストアを実行するための最速の復元ポイントとして使用して、復元時間を最大 90% 短縮できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、1 から 35 日の範囲でデータベース バックアップを構成できます。 ポータルから合計 50 個のオンデマンド バックアップをトリガーできます。 すべてのバックアップの保存データは、AES 256 ビット暗号化を使用して暗号化されます。

これらのバックアップ ファイルをエクスポートすることはできません。 バックアップは、フレキシブル サーバーでの復元操作にのみ使用できます。 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 冗長ストレージに移動するには、新しいサーバーを作成し、ダンプと復元を使用してデータを移行することが、サポートされている唯一のオプションです。

バックアップ保有期間

バックアップは、サーバーのバックアップ保有期間の設定に基づいて保持されます。 保有期間は 1 から 35 日の範囲で選択でき、既定の保有期間は 7 日です。 Azure portal を使用してバックアップ構成を更新することで、サーバーの作成中またはその後で保有期間を設定することができます。

ポイントインタイム リストアは使用可能なバックアップに基づいているため、その操作を現在からどのくらい遡って実行できるかは、バックアップの保有期間によって管理されます。 バックアップの保有期間は、復元の観点から回復期間として扱うこともできます。 バックアップ保有期間内の特定の時点に復旧するために必要なすべてのバックアップは、バックアップ ストレージに保持されます。 たとえば、バックアップの保有期間が 7 日に設定されている場合、回復期間は過去 7 日間と見なされます。 このシナリオでは、過去 7 日間のサーバーを復元するために必要なすべてのバックアップが保持されます。 バックアップ保有期間が 7 日の場合、データベース スナップショットとトランザクション ログ バックアップは、過去 8 日間 (期間の 1 日前まで) について格納されます。

バックアップ ストレージのコスト

フレキシブル サーバーを使用すると、プロビジョニングされているサーバー ストレージの最大 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 ペア リージョンに復元できます。 他のリージョンへの geo リストアは現在サポートされていません。

サーバーの復旧にかかる推定時間は、次のいくつかの要因によって異なります。

  • データベースのサイズ
  • 関連するトランザクション ログ数
  • 復元時点に復旧するために再生の必要があるアクティビティ量
  • 別のリージョンへの復元の場合は、ネットワーク帯域幅
  • ターゲット リージョンで処理される、同時実行される復元要求の数
  • データベース内のテーブルに主キーが存在するかどうか。 高速復旧を行うには、データベース内のすべてのテーブルに主キーを追加することを検討してください。

注意

高可用性が有効になっているサーバーは、ポイントインタイム リストアと geo リストアの両方を復元した後に、非 HA (高可用性が無効になっている) サーバーになります。

ポイントインタイム リストア

Azure Database for MySQL フレキシブル サーバーでは、ポイントインタイム リストアを実行すると、ソース サーバーと同じリージョンに、フレキシブル サーバーのバックアップから新しいサーバーが作成されます。 コンピューティング レベル、仮想コア数、ストレージ サイズ、バックアップ保有期間、バックアップ冗長オプションについては、元のサーバーの構成で作成されます。 また、仮想ネットワークやファイアウォールなどのタグと設定は、ソース サーバーから継承されます。 復元されたサーバーのコンピューティング レベルとストレージ レベル、構成、セキュリティの設定は、復元が完了した後で変更できます。

注意

復元操作の後で既定値にリセットされる (そして、プライマリ サーバーからコピーで上書きされない) サーバー パラメーターが 2 つあります

  • time_zone - この値は、既定値 SYSTEM に設定されます
  • event_scheduler - 復元されたサーバーでは event_scheduler は OFF に設定されます

ポイントインタイム リストアは複数のシナリオで役に立ちます。 一般的なユース ケースとしては、次のようなものがあります。

  • ユーザーがデータベース内のデータを誤って削除した場合
  • ユーザーが重要なテーブルまたはデータベースを削除する
  • ユーザー アプリケーションの欠陥のため、正しいデータが不適切なデータで誤って上書きされる。

最新の復元ポイント、カスタム復元ポイント、Azure portal を介した最速の復元ポイント (完全バックアップを使用した復元) から選択できます。

  • 最新の復元ポイント: 最新の復元ポイントのオプションは、復元操作がトリガーされたときのタイムスタンプにサーバーを復元するために役立ちます。 このオプションは、サーバーを最も更新された状態にすばやく復元するのに役立ちます。
  • カスタム復元ポイント: これを使用すると、このフレキシブル サーバーに定義されている保有期間内の特定の時点を選択できます。 このオプションは、ユーザー エラーから復旧するために、サーバーを正確な時点まで復元する場合に便利です。
  • 最速の復元ポイント: このオプションを使用すると、ユーザーは、フレキシブル サーバーに対して定義された保有期間内に、可能な限り最速の時間でサーバーを復元できます。 最速の復元は、完全バックアップが完了した時点の復元ポイントを選択することで可能です。 この復元操作では、スナップショットの完全バックアップが復元されるだけで、高速になるログの復元や復旧は保証されません。 復元操作を正常に実行するには、最も古い復元ポイントを超える完全バックアップ タイムスタンプを選択することをお勧めします。

復旧にかかる推定時間は、データベースのサイズ、トランザクション ログのバックアップ サイズ、SKU のコンピューティング サイズ、復元の時刻など、いくつかの要因によって異なります。 トランザクション ログの復旧は、復元プロセスの中で最も時間がかかる部分です。 スナップショット バックアップのスケジュールに近い復元時刻を選択すると、トランザクション ログの適用が最小限になるため、復元操作の速度が速くなります。 サーバーの復旧時間を正確に見積もるには、環境に固有の変数が多すぎるため、実際の環境でテストすることを強くお勧めします。

重要

ゾーン冗長の高可用性を使用して構成されたフレキシブル サーバーを復元する場合、復元されたサーバーは、プライマリ サーバーと同じリージョンおよびゾーン内に構成され、非 HA モードで単一のフレキシブル サーバーとしてデプロイされます。 フレキシブル サーバーに対するゾーン冗長高可用性に関するページを参照してください。

重要

削除された MySQL フレキシブル サーバー リソースは、サーバーを削除した時点から 5 日以内であれば復元できます。 削除されたサーバーを復元する方法の詳細なガイドについては、文書化されている手順を参照してください。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを利用できます。

geo リストア

geo 冗長バックアップ用にサーバーを構成した場合は、サービスを使用できる geo ペア リージョンにサーバーを復元できます。 他のリージョンへの geo リストアは現在サポートされていません。

geo リストアは、サーバーがホストされているリージョンでのインシデントが原因でサーバーが利用できない場合の既定の復旧オプションです。 リージョン内の大規模なインシデントにより、データベース アプリケーションが使用できなくなった場合、geo 冗長バックアップから他の任意のリージョン内のサーバーに、サーバーを復元できます。 geo リストアでは、サーバーの最新のバックアップが利用されます。 バックアップが取得される時刻と、別のリージョンにそのバックアップがレプリケートされる時刻には時間差があります。 この時間差は最大 1 時間なので、障害が発生した場合、最大 1 時間分のデータが損失する可能性があります。

geo リストア中に変更できるサーバー構成には、セキュリティ構成 (ファイアウォール規則と仮想ネットワーク設定) のみが含まれます。 geo リストア中に、コンピューティング、ストレージ、価格レベル (Basic、General Purpose、または Business Critical) など、他のサーバー構成を変更することはできません。

Azure CLI を利用して、停止されたサーバーで geo リストアを実行することもできます。 Azure CLI を使用したサーバーの geo リストアの詳細については、「Azure CLI を使用して Azure Database for MySQL - フレキシブル サーバーを復元する」をご覧ください。

復旧の推定所要時間は、データベースのサイズ、トランザクション ログのサイズ、ネットワーク帯域幅、同じリージョン内で同時に復旧するデータベースの合計数など、複数の要因によって異なります。

注意

ゾーン冗長の高可用性を使用して構成されたフレキシブル サーバーを geo 復元する場合、復元されたサーバーは、geo ペア リージョンと、プライマリ サーバーと同じゾーン内に構成され、非 HA モードで単一フレキシブル サーバーとしてデプロイされます。 フレキシブル サーバーに対するゾーン冗長高可用性に関するページを参照してください。

重要

プライマリ リージョンがダウンすると、プライマリ リージョンでストレージをプロビジョニングできなくなるため、geo 冗長サーバーをそれぞれの geo ペア リージョンに作成できません。 geo ペア リージョンで geo 冗長サーバーをプロビジョニングするには、プライマリ リージョンが稼働するまで待機する必要があります。 プライマリ リージョンがダウンしていても、ソース サーバーを geo ペア リージョンに geo リストアすることはできます。それには、復元ポータル操作により [コンピューティングとストレージ] の [サーバーの構成] 設定で geo 冗長オプションを無効にし、ローカル冗長サーバーとして復元してビジネス継続性を確保します。

復元後のタスクの実行

最新の復元ポイントまたはカスタム復元ポイントのいずれかの復旧メカニズムで復元した後、ユーザーとアプリケーションを元に戻して実行するには、次のタスクを実行する必要があります。

  • 元のサーバーを新しいサーバーで置き換える場合は、クライアントとクライアント アプリケーションを新しいサーバーにリダイレクトします。
  • ユーザーが接続できるように、サーバー レベルの適切なファイアウォール規則と仮想ネットワーク規則が適用されていることを確認します。
  • 適切なログインとデータベース レベルのアクセス許可が指定されていることを確認します。
  • 必要に応じて、アラートを構成する。

よく寄せられる質問 (FAQ)

  • サーバーをバックアップするにはどうすればよいですか。 既定では、Azure Database for MySQL によって、サーバー全体 (作成されたすべてのデータベースを含む) の自動バックアップが有効になります。保有期間は、既定では 7 日間です。 オンデマンド バックアップ機能を使用して手動バックアップをトリガーすることもできます。 バックアップを手動で作成する別の方法は、コミュニティ ツールを使用することです。たとえば、mysqldump (ドキュメントはこちら)、mydumper (ドキュメントはこちら) などを使用します。 Azure Database for MySQL を BLOB ストレージにバックアップする場合は、「Azure Database for MySQL を BLOB ストレージにバックアップする」という Tech Community ブログを参照してください。

  • 自動バックアップが長期間保有されるように構成できますか。 いいえ。現在サポートされているのは、最大 35 日間の自動バックアップ保有のみです。 手動バックアップを作成して、それを長期保有の要件に対して使用することができます。

  • サーバーのバックアップ ウィンドウとは何ですか? カスタマイズできますか? 初回のスナップショット バックアップは、サーバーの作成直後にスケジュールされます。 スナップショット バックアップは、毎日 1 回作成されます。 トランザクション ログ バックアップは 5 分ごとに実行されます。 バックアップの時間帯は本質的に Azure によって管理されており、カスタマイズできません。

  • バックアップは暗号化されますか? クエリの実行中に作成されたすべての Azure Database for MySQL データ、バックアップ、一時ファイルは、AES 256 ビット暗号化を使用して暗号化されます。 ストレージの暗号化は常にオンになっており、無効にすることはできません。

  • 単一または少数のデータベースを復元できますか。 単一または少数のデータベースおよびテーブルの復元はサポートされていません。 特定のデータベースを復元する場合は、ポイントインタイム リストアを実行してから、必要なテーブルまたはデータベースを抽出します。

  • バックアップの時間帯にサーバーを使用できますか。 はい。 バックアップはオンライン操作であり、スナップショットベースです。 スナップショット操作には数秒しかかからず、運用環境のワークロードには影響しないため、サーバーの高可用性が確保されます。

  • サーバーのメンテナンス期間を設定するときに、バックアップの時間帯を考慮する必要がありますか。 いいえ。バックアップは管理サービスの一部として内部的にトリガーされ、管理されたメンテナンス期間には関係しません。

  • 自動バックアップはどこに格納され、その保有期間はどのように管理できますか。 Azure Database for MySQL では、サーバーのバックアップが自動的に作成され、ユーザーが構成したローカル冗長ストレージまたは geo 冗長ストレージに格納されます。 これらのバックアップ ファイルをエクスポートすることはできません。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、1 から 35 日の範囲でデータベース バックアップを構成できます。

  • バックアップを検証するにはどうすればよいですか。 正常に完了したバックアップの可用性を検証する最善の方法は、[バックアップと復元] ブレードで、保有期間中に作成された完全な自動バックアップを表示する方法です。 バックアップが失敗した場合、バックアップは使用可能なバックアップの一覧に表示されません。バックアップ サービスは、バックアップが正常に作成されるまで 20 分ごとにバックアップを試します。 これらのバックアップ エラーは、サーバーでのトランザクションの実稼働負荷が高い場合に発生します。

  • バックアップの使用量はどこで確認できますか。 Azure portal の [監視] タブの [メトリック] セクションに、使用済みバックアップ ストレージのメトリックがあります。これは、バックアップの使用量の合計を監視するために役立ちます。

  • サーバーを削除した場合、バックアップはどうなりますか。 サーバーを削除すると、そのサーバーに属するバックアップもすべて削除され、復元できなくなります。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを利用できます。

  • バックアップの使用に対して、どのように課金および請求が行われますか。 フレキシブル サーバーを使用すると、プロビジョニングされているサーバー ストレージの最大 100% までが、バックアップ ストレージとして追加コストなしで提供されます。 バックアップ ストレージを追加で使用した場合は、価格モデルに基づき、1 か月ごとに GB 単位で請求されます。 また、バックアップ ストレージの課金には、使用されるバックアップ ストレージの合計使用量に直接影響するサーバー上のトランザクション アクティビティとは別に、選択されたバックアップ保有期間と、選択されたバックアップ冗長性オプションも関与します。

  • 停止したサーバーのバックアップはどのように保有されますか。 停止したサーバーに対して、新しいバックアップは実行されません。 サーバーを停止した時点でのすべての古いバックアップ (保有期間内のもの) は、サーバーが再起動されるまで保有されます。その後、アクティブなサーバーのバックアップの保有は、そのバックアップ保有期間によって管理されます。

  • 停止しているサーバーのバックアップについては、どのように請求されますか。 サーバー インスタンスが停止している間は、プロビジョニングされたストレージ (プロビジョニングされた IOPS を含む) とバックアップ ストレージ (指定した保有期間内の格納されているバックアップ) に対して課金されます。 無料バックアップ ストレージは、プロビジョニングしたデータベースのサイズに制限され、アクティブなサーバーにのみ適用されます。

  • サーバーを復元するにはどうすればよいですか。 Azure portal ではポイントインタイム リストアがサポートされ (すべてのサーバーが対象)、ユーザーは最新またはカスタムの復元ポイントに復元できます。 mysqldump/myDumper によって作成されたバックアップからサーバーを手動で復元するには、「myLoader を使用してデータベースを復元する」を参照してください。

  • 復元に長時間かかるのはなぜですか。 サーバーの復旧にかかる推定時間は、次のいくつかの要因によって異なります。

    • データベースのサイズ。 復旧プロセスの一環として、データベースを最新の物理バックアップからハイドレートする必要があるため、復旧にかかる時間はデータベースのサイズに比例します。
    • 復旧のために再生する必要があるトランザクション アクティビティのアクティブな部分。 最後に成功したチェックポイント以降の追加のトランザクション アクティビティによっては、復旧に時間がかかる場合があります。
    • 別のリージョンへの復元の場合は、ネットワーク帯域幅
    • ターゲット リージョンで処理される、同時実行される復元要求の数
    • データベース内のテーブルに主キーが存在するかどうか。 高速復旧を行うには、データベース内のすべてのテーブルに主キーを追加することを検討してください。
  • セッション レベルのデータベース変数の変更は復元に影響しますか? セッション レベル変数を変更し、MySQL クライアント セッションで DML ステートメントを実行すると、PITR (ポイントインタイム リストア) 操作に影響を与える可能性があります。これらの変更は、バックアップおよび復元操作に使用されるバイナリ ログに記録されないためです。 たとえば、 foreign_key_checks はこのようなセッション レベル変数の 1 つであり、外部キー制約に違反する DML ステートメントを実行するために無効にすると、PITR (ポイントインタイム リストア) エラーが発生します。 このようなシナリオの唯一の回避策は、foreign_key_checks が無効になった時刻よりも前の PITR 時刻を選択することです。 PITR 操作が成功するようにセッション変数を変更しないことをお勧めします。

次のステップ