tencent cloud

データを喪失または破損させないために、自動バックアップまたは手動バックアップによってデータベースをバックアップできます。

バックアップの概要

バックアップモード

TencentDB for MySQL単一ノード（クラウドディスク）、2ノード（ローカルディスク）、および3ノード（ローカルディスク）は、自動バックアップと手動バックアップという2つのデータベースバックアップ方法をサポートしています。

バックアップタイプ

**TencentDB for MySQLの2ノード、3ノードは次の2種類のバックアップタイプに対応します：

• 物理バックアップ：物理データを完全コピーすることです（自動バックアップと手動バックアップの両方でサポート）。
• 論理バックアップ：SQLステートメントをバックアップすることです（手動バックアップへのサポート）。

  説明：

  • 物理バックアップを使用してデータベースを復元するには、xbstreamを利用してパッケージを解凍する必要があります。詳細については、物理バックアップでデータベースを復元するをご参照ください。
  • 単一インスタンスのテーブル数が100万を超えた場合は、バックアップのエラーになる恐れがあり、データベースへの監視にも影響を与えます。そのために、単一インスタンスのテーブル数が100万を超えないようにテーブルの数を適切に管理してください。
  • Memoryエンジンテーブルのデータがメモリに格納されているので、Memoryエンジンテーブルの物理バックアップを実行できません。データの紛失を避けるために、MemoryエンジンテーブルをInnoDBテーブルに置き換えることをお勧めします。
  • インスタンスにはプライマリキーのないテーブルが多数存在するため、バックアップに失敗し、インスタンスの高可用性に影響を与える可能性があります。プライマリキーのないテーブルのプライマリキーまたはセカンダリインデックスを適時に作成してください。

物理バックアップのメリット	論理バックアップのデメリット
バックアップ速度が速いです。 ストリーミングバックアップと圧縮をサポートします。 バックアップの成功率が高いです。 復元は簡単で効率的です。 バックアップとの結合作業、例えば、ROの増加、災害復旧の増加で速度がより速くなります。 物理バックアップにかかる平均時間は論理バックアップの1/8程度です。 物理バックアップのインポート速度は論理バックアップより10倍ほど速いです。	復元するにはSQLの実行とインデックスの作成が必要なので、かかる時間が長くなります。 バックアップ速度が遅いです。大量のデータがある場合は特に速度が低下します。 バックアッププロセスは、インスタンスに負荷をかけ、マスター/スレーブの遅延を大きくする可能性があります。 単精度浮動小数点数の精度情報が紛失する可能性があります。 各種エラー（エラービューなど）によって、バックアップの失敗になる可能性があります。 バックアップとの結合作業、例えば、ROの増加、災害復旧の増加で速度が遅くなる可能性があります。

TencentDB for MySQLの1ノード（クラウドディスク）がスナップショットバックアップをサポート：
スナップショットバックアップ：ストレージ階層のディスクのスナップショットを作成してバックアップします（自動バックアップと手動バックアップの両方がサポートされます）。

スナップショットバックアップのメリット	スナップショットバックアップのデメリット
バックアップ速度が速いです。 使用する容量が比較的小さいです。	ダウンロードをサポートしていません。

バックアップのオブジェクト

データバックアップ	ログバックアップ
MySQL 2ノード、3ノード： 自動バックアップは全データの物理バックアップをサポートしています。 手動バックアップは全データの物理バックアップ、全データの論理バックアップと単一データベース、単一テーブルの論理バックアップをサポートしています。 自動バックアップと手動バックアップの両方とも圧縮とダウンロードをサポートしています。 MySQL単一ノード（クラウドディスク）： 自動バックアップは全データのスナップショットバックアップをサポートしています。 手動バックアップは全データのスナップショットバックアップをサポートしています。 自動バックアップと手動バックアップの両方ともダウンロードをサポートしていません。	データベースのbinlogログファイルバックアップはMySQL単一ノード（クラウドディスク）、2ノード、3ノードに対応可能： ログファイルはインスタンスバックアップの容量を使用します。 ログファイルはダウンロードをサポートしていますが、圧縮をサポートしていません。 ログファイルの保存期間を設定できます。

注意事項

• MySQLの自動バックアップ機能は、2019年02月26日より、物理バックアップのみサポートされています。自動バックアップは、デフォルトで物理バックアップに設定され、論理バックアップを提供されなくなりました。既存の自動論理バックアップは、自動的に物理バックアップに切り替えられます。
  この切り替え作業は、サービスへのアクセスに影響を与えませんが、自動バックアップを使う習慣のある方に若干の影響を与える可能性があります。論理バックアップを実行したい場合、 MySQLコンソール の手動バックアップ方法、或いはAPIの呼び出しで論理バックアップを生成することができます。
• インスタンスバックアップファイル占用バックアップキャパシティについては、バックアップキャパシティを適切に使用してください。バックアップキャパシティが無料制限を超えたものには課金されます。 バックアップスペース課金説明をご参照ください。
• サービス量の少ない時期にデータベースをバックアップすることをお勧めします。
• 一定の保持期間を過ぎた場合、ファイルが自動的に削除されますので、必要なバックアップファイルをローカルにダウンロードしてください。
• テーブルロックによるバックアップの失敗を回避するために、バックアップ中は、DDL操作をしないでください。
• 単一ノードのMySQLインスタンスはデータベースのバックアップをサポートしていません。

MySQLデータの自動バックアップ

自動バックアップの設定

1. MySQLコンソールにログインし、インスタンスリストのページでインスタンスIDをクリックすると、管理ページに進み、バックアップと復元 > 自動バックアップの設定を選択します。
   
2. バックアップ設定のためのポップアップダイアログで、バックアップパラメータを選択し、OKをクリックします。パラメータは次のように説明されています：

   説明：

   • ロールバック機能 は、バックアップサイクルとバックアップ保持日数内のデータバックアップ + ログバックアップ（binlog）を基準にしています。自動バックアップ頻度と保持日数を短縮すると、インスタンスデータのロールバック期間の範囲に影響します。バックアップの設定は十分に検討してください。
     例えば、バックアップサイクルを月曜と木曜、保持日数を7日間に設定すると、7日以内（データバックアップとログの有効バックアップの実際の保存期間）の任意の時点でロールバックできます。
   • 自動バックアップしたものは手動で削除することはできませんが、バックアップ保持期間を設定して、期限がきたら自動削除することができます。
   • データバックアップとログバックアップの保持日数を追加すると予定外のバックアップキャパシティ費用が生じる恐れがあります。
   • ログバックアップの保持日数を短縮するとインスタンスのデータロールバックサイクルに影響する恐れがあります。

自動バックアップ設定では、データバックアップの設定について定期保持を有効にすることをサポートしています。定期保持を有効にしていない設定は通常バックアップ設定と呼ばれます。以下では、通常バックアップ設定および定期バックアップ設定を有効にするの各パラメータについて説明します。

通常バックアップの設定説明

パラメータ	説明
バックアップ開始時間	デフォルトの時間はシステムが自動的に割り当てたバックアップ開始時刻です。 バックアップ開始時間帯（02:00～06:00など）をカスタム設定でき、サービスの低いピーク期間に設定することをお勧めします。バックアップ開始時刻は、バックアップ終了時刻ではなく、バックアップが開始する時刻を表します。 例えば、02:00～06:00時を選択した場合、システムは、02:00～06:00の時間帯にある特定の時刻にバックアップを開始します。具体的な開始時刻は、バックエンドのバックアップポリシーとバックアップシステム状況に依存します。
データバックアップの保存時間	MySQL 2ノード、3ノードのデータバックアップファイルは7日～1830日保存可能で、デフォルトで7日間保存されます。期限を過ぎると、バックアップセットは自動削除されます。 MySQL単一ノード（クラウドディスク）のデータバックアップファイルは7日～1830日保存可能で、デフォルトで7日間保存されます。期限を過ぎると、バックアップセットは自動削除されます。
バックアップサイクル	設定ルール： 週ごとの設定：デフォルトでは月曜日から日曜日までの7日間が選択され、バックアップ時刻のカスタマイズをサポートしています。ただし、データの安全性を確保するために、週に2回以上バックアップするように設定してください。 月ごとの設定：データを安全に保つため、1か月のうち、隣接する2つの日付の間隔は2日を超えないようにしてください。例えば、バックアップ日として1日を選択した場合、次回のバックアップ日に2日、3日、4日を省略して5日を選択することはできません。 説明
コールドバックアップへのダウングレード（オプション）	適切なコールドバックアップへのダウングレードポリシーを選択し、日数を指定します： 標準ストレージ日数を指定します。つまり、データバックアップファイルが生成された日から標準ストレージにダウングレードするまでの経過日数を設定します。 アーカイブストレージ日数の指定：、データバックアップファイルが生成された日からアーカイブストレージにダウングレードするまでの経過日数を設定します。 コールドバックアップへのダウングレード手順とポリシーの詳細については、コールドバックアップへのダウングレード設定をご参照ください。このうち、アーカイブストレージ機能は現在オープンではありませんので、しばらくお待ちください。
ログバックアップの保存時間	MySQL 2ノード、3ノードのログバックアップファイルは7日～1830日保存可能で、デフォルトで7日間保存されます。期限を過ぎると、バックアップセットは自動削除されます。 MySQL単一ノード（クラウドディスク）のログバックアップファイルは7日～1830日保存可能で、デフォルトで7日間保存されます。期限を過ぎると、バックアップセットは自動削除されます。
コールドバックアップへのダウングレード（オプション）	適切なbinlogコールドバックアップへのダウングレードポリシーを選択し、日数を指定します： 標準ストレージ日数を指定します。つまり、binlogファイルが生成された日から標準ストレージにダウングレードするまでの経過日数を設定します。 アーカイブストレージ日数の指定：binlogファイルが生成された日からアーカイブストレージにダウングレードするまでの経過日数を設定します。 コールドバックアップへのダウングレード手順とポリシーの詳細については、コールドバックアップへのダウングレード設定をご参照ください。このうち、アーカイブストレージ機能は現在オープンではありませんので、しばらくお待ちください。

定期バックアップ設定を有効化する説明

説明：

-　単一ノード（クラウドディスク）のインスタンスは、現在定期的なバックアップ設定機能をサポートしていません。

• 定期バックアップの保持時間は設定された通常バックアップ保持時間よりも長くしてください。

パラメータ	説明
バックアップ開始時間	デフォルトの時間はシステムが自動的に割り当てたバックアップ開始時刻です。 バックアップ開始時間帯（02:00～06:00など）をカスタム設定でき、サービスの低いピーク期間に設定することをお勧めします。バックアップ開始時刻は、バックアップ終了時刻ではなく、バックアップが開始する時刻を表します。 例えば、02:00～06:00時を選択した場合、システムは、02:00～06:00の時間帯にある特定の時刻にバックアップを開始します。具体的な開始時刻は、バックエンドのバックアップポリシーとバックアップシステム状況に依存します。
データバックアップの保持時間	MySQLの2ノード・3ノードデータバックアップファイルは7日～1830日保持でき、デフォルト値は7日です。期限がきたらバックアップセットは自動削除されます。
バックアップサイクル	設定ルール： 週ごとの設定：デフォルトでは月曜日から日曜日までの7日間が選択され、バックアップ時刻のカスタマイズをサポートしています。ただし、データの安全性を確保するために、週に2回以上バックアップするように設定してください。 月ごとの設定：データを安全に保つため、1か月のうち、隣接する2つの日付の間隔は2日を超えないようにしてください。例えば、バックアップ日として1日を選択した場合、次回のバックアップ日に2日、3日、4日を省略して5日を選択することはできません。 説明
定期バックアップの保持時間	データバックアップファイルは90日～3650日保持でき、デフォルト値は1080日です。保持期限がきたらバックアップセットは自動削除されます。
定期バックアップ保持ポリシー	月、四半期または年ごとのバックアップ保持数の設定をサポートします。
開始時刻	定期保持バックアップの開始時刻を実行します。
コールドバックアップへのダウングレード（オプション）	適切なコールドバックアップへのダウングレードポリシーを選択し、日数を指定します： 標準ストレージ日数を指定します。つまり、データバックアップファイルが生成された日から標準ストレージにダウングレードするまでの経過日数を設定します。 アーカイブストレージ日数の指定：、データバックアップファイルが生成された日からアーカイブストレージにダウングレードするまでの経過日数を設定します。 コールドバックアップへのダウングレード手順とポリシーの詳細については、コールドバックアップへのダウングレード設定をご参照ください。このうち、アーカイブストレージ機能は現在オープンではありませんので、しばらくお待ちください。
ログバックアップの保持時間	ログバックアップファイルは7日～1830日保持でき、デフォルト値は7日です。期限がきたらバックアップセットは自動削除されます。
コールドバックアップへのダウングレード（オプション）	適切なbinlogコールドバックアップへのダウングレードポリシーを選択し、日数を指定します： 標準ストレージ日数を指定します。つまり、binlogファイルが生成された日から標準ストレージにダウングレードするまでの経過日数を設定します。 アーカイブストレージ日数の指定：binlogファイルが生成された日からアーカイブストレージにダウングレードするまでの経過日数を設定します。 コールドバックアップへのダウングレード手順とポリシーの詳細については、コールドバックアップへのダウングレード設定をご参照ください。このうち、アーカイブストレージ機能は現在オープンではありませんので、しばらくお待ちください。

保持計画の確認

バックアップ設定で定期バックアップ保持ポリシーを選択した後、保持計画を確認をクリックしてプレビューが表示されます。

• 青い日付は通常バックアップの期日を意味します。
• 赤い日付は定期バックアップの期日を意味します。
• 通常バックアップまたは定期バックアップをクリックして、プレビューのため、対応する日付の色分けを非表示します。
• バックアップ計画のプレビューは今後1年間のバックアップ保持状況であり、参考用です。

デモ1：バックアップサイクルは月曜、水曜、金曜、日曜。2022年1月11日から、各月に1つのバックアップを保持します。

デモ2：バックアップサイクルは月曜、水曜、金曜。2022年1月11日から、各四半期に3つのバックアップを保持します。

デモ3：定期バックアップのみが表示されます。

MySQLデータの手動バックアップ

手動バックアップ機能を使用すると、バックアップタスクを手動で開始できます。

説明：

• MySQL 2ノード、3ノードのインスタンスの手動バックアップは、全データの物理バックアップ、全データの論理バックアップ、および単一データベース、単一テーブルの論理バックアップをサポートしています。
• MySQL 2ノード、3ノードのインスタンスの手動バックアップをバックアップリストで手動で削除することで、バックアップ容量をリリースして、容量の浪費と不必要な使用を回避できます。手動で削除しない限り、データベースインスタンスがオフラインになるまで保存されます。
• MySQL単一ノード（クラウドディスク）のインスタンスは全データのスナップショットバックアップをサポートしています。
• MySQL単一ノード（クラウドディスク）のインスタンスの手動バックアップは削除をサポートしていません。
• インスタンスは毎日の自動バックアップタスクを実行する期間内に手動バックアップを開始することができません。

MySQL 2ノード、3ノードのインスタンスの操作手順

1. MySQLコンソールにログインし、インスタンスリストのページでインスタンスIDをクリックすると、管理ページに進み、バックアップと復元 > 自動手動バックアップを選択します。
2. バックアップ設定のポップアップダイアログで、バックアップ方法とオブジェクトを選択して、備考名を入力し、OKをクリックします。
   

   説明：

   単一データベース/テーブルの論理バックアップの場合、左側のデータベースとテーブルの選択でバックアップするデータベース又はテーブルを選択し、データベース又はテーブルを右側のリストに追加します。データベースがない場合は、まずデータベース或いはテーブルを作成してください。

   

MySQL単一ノード（クラウドディスク）のインスタンスの操作手順

1. MySQLコンソールにログインし、インスタンスリストでターゲットインスタンスIDをクリックして管理ページに移動してから、バックアップ復元 > 手動バックアップを選択します。
2. 備考名を入力し、確定をクリックします。
   

よくあるご質問

1. バックアップ保持期間が過ぎたバックアップは、まだダウンロードや元に戻すことができますか？

期限切れのバックアップセットは自動的に削除され、ダウンロードまたは復元できません。

• 必要に応じてバックアップ保存時間を適切に設定する、またはMySQLコンソールでバックアップファイルをデバイス内にダウンロードすることをお勧めします（注意：単一ノードのクラウドディスクインスタンスのバックアップファイルは、現在ダウンロードをサポートしていません）。
• コンソールでインスタンスデータを手動でバックアップすることもでき、手動バックアップは永続的に保持されます。

  説明：

  手動バックアップは、バックアップキャパシティを占用することもあります。バックアップキャパシティを適切に使用して、予定外の費用が生じないようにしてください。

2. バックアップは手動で削除できますか？

• 自動バックアップしたものは手動で削除することはできませんが、バックアップ保持期間を設定して、期限がきたら自動削除することができます。
• 2ノード、3ノードのインスタンスの手動バックアップは、MySQLコンソールのバックアップリストから手動で削除できます。手動で削除しない限り、バックアップは永久に保存されます。単一ノードのクラウドディスクインスタンスの手動バックアップは、現在削除をサポートしていません。

3. データとログのバックアップは停止できますか？

無効にできません。ただし、MySQLコンソールからバックアップ頻度を削減し、今後使用しない手動バックアップデータを削除することで、バックアップ容量の使用量を削減することができます（単一ノードのクラウドディスクインスタンスの手動バックアップは、現在削除をサポートしていません）。

4. どのようにしてバックアップキャパシティのオーバーヘッドを減らしますか？

• 今後使用しない手動バックアップデータを削除します（手動バックアップはMySQLコンソールのインスタンス管理ページ > バックアップ復元ページで削除できます。注意：単一ノードのクラウドディスクインスタンスの手動バックアップは、現在削除をサポートしていません）。
• 非コアビジネスのデータの自動バックアップ頻度を減らします（コンソールでバックアップ周期とバックアップ保留時間を調整することができ、1週間に少なくとも2回バックアップします）。

  説明：

  ロールバック機能 は、バックアップサイクルとバックアップ保持日数内のデータバックアップ+ ログバックアップ（binlog）を基準にしています。自動バックアップ頻度と保持日数を短縮すると、インスタンスデータのロールバック期間の範囲に影響します。バックアップの設定は十分に検討してください。

• 非コアビジネスのデータバックアップおよびログバックアップの保存時間を短縮します(7日間のバックアップ保留時間は、既に大部分のシナリオの要件を満たすことができます)。
• コールドバックアップへのダウングレードの設定でコールドバックアップへのダウングレードポリシーを設定し、バックアップファイルのストレージタイプを変換し、ストレージコストを削減させます。

サービスケース	バックアップ保留時間
コアビジネス	7日～3650日はおすすめです。バックアップの長期保存のために定期バックアップを有効にすることをおすすめします
中核でない、データ類でないサービス	7日をお勧めします
アーカイブ類サービス	バックアップの保留時間を7日間とし、実際のサービスニーズにより手動でデータをバックアップし、使い終わったら適時に削除することをお勧めします
テスト類サービス	バックアップの保留時間を7日間とし、実際のサービスニーズにより手動でデータをバックアップし、使い終わったら適時に削除することをお勧めします