データベースのバックアップ
Download
フォーカスモード
フォントサイズ
データ紛失または破損を防ぐために、自動バックアップまたは手動バックアップの方法でデータベースをバックアップできます。
バックアップ概要
バックアップ方式
TencentDB for MySQL シングルノード（クラウドディスク）、デュアルノード（ローカルディスク）、トリプルノード（ローカルディスク）、クラウドディスク版（クラウドディスク）は、自動バックアップおよび手動バックアップの2つの方法でデータベースをバックアップすることをサポートしています。
バックアップタイプ
TencentDB for MySQL デュアルノードおよびトリプルノードは、2種類のバックアップタイプをサポートしています：
物理バックアップ：物理データのフルコピー（自動バックアップでサポートされています）。
論理バックアップ：SQL文のバックアップ（手動バックアップおよび自動バックアップの両方でサポートされています）。
説明：
物理バックアップの復元方式では、xbstreamを使用して解凍する必要があります。詳細な操作については、物理バックアップを使用したデータベースの復元を参照してください。
1つのインスタンスにおけるテーブル数が30万を超えると、バックアップに失敗する可能性があります。また、データベース監視にも影響を及ぼすため、テーブル数を適切に管理し、1インスタンスあたり30万テーブル以下に抑えてください。
バックアップ時間は、データベースのデータファイルのサイズおよびテーブル数に比例します。データファイルが大きい、またはテーブル数が多いほど、バックアップ時間は長くなります。
Memoryエンジンテーブルのデータはメモリに保存されているため、Memoryエンジンテーブルに対して物理バックアップを行うことはできません。データの紛失を避けるために、MemoryエンジンテーブルをInnoDBテーブルに変換することを推奨します。
インスタンスにプライマリキーのないテーブルが多数存在する場合、バックアップの失敗につながる可能性があります。同時にインスタンスの高可用性にも影響を及ぼす可能性があります。プライマリキーまたはセカンダリインデックスのないテーブルに対して、速やかにプライマリキーまたはセカンダリインデックスを作成してください。
手動バックアップ > ロジックコールドバックアップ操作を行うとグローバルリードロックが発生します。コンソール経由でこの操作を行うことを推奨します（コンソールからのロジックコールドバックアップタスクはスレーブインスタンスに対して行われるため、マスターインスタンスには影響しません）。
物理バックアップのメリット | 論理バックアップのデメリット。 |
バックアップ速度が速いです。 ストリーミングバックアップと圧縮をサポートします。 バックアップの成功率が高いです。 復元は簡単で効率的です。 バックアップに依存した結合操作、例えば、ROの追加や災害復旧の追加などは、より速くなります。 物理バックアップの平均所要時間は、論理バックアップの約8分の1程度です。 物理バックアップのインポート速度は、論理バックアップのインポートより10倍程度速いです。 | 復元時にはSQLの実行とインデックスの構築が必要となり、復元には時間がかかります。 バックアップ速度が遅いです。データ量が大きい場合、特に顕著です。 バックアップ中にはインスタンスに負荷がかかり、マスター/スレーブ間の遅延が増加する可能性があります。 浮動小数点数の精度情報を失う可能性があります。 様々な問題（エラービューなど）により、バックアップが失敗する可能性があります。 バックアップに依存した結合操作。例えば、ROの追加や災害復旧の追加などは遅くなります。 |
TencentDB for MySQL シングルノード（クラウドディスク）、クラウドディスク版（クラウドディスク）はスナップショットバックアップをサポートします。
スナップショットバックアップ：ストレージ層のディスクにスナップショットを作成する方式でバックアップを行います（自動バックアップと手動バックアップのいずれもサポートします）。
説明：
シングルノード（クラウドディスク）インスタンスは単一ノード構成のため、バックアップはマスターノード上で実行されます。バックアップを行う場合は、ビジネスのオフピーク時間帯に操作することを推奨します。
スナップショットバックアップのメリット | スナップショットバックアップのデメリット |
バックアップ速度が速いです。 相対的に占有スペースが小さいです。 | ダウンロードはサポートされていません。 |
バックアップ対象
データバックアップ | ログバックアップ |
MySQL デュアルノード、トリプルノード： 自動バックアップはフル物理バックアップをサポートします。 手動バックアップは、フル物理バックアップ、フル論理バックアップ、および単一データベース・単一テーブルの論理バックアップをサポートします。 自動バックアップと手動バックアップはともに圧縮とダウンロードをサポートします。 MySQL シングルノード（クラウドディスク）、クラウドストレージ版（クラウドディスク）： 自動バックアップはフルスナップショットバックアップをサポートします。 手動バックアップはフルスナップショットバックアップをサポートします。 自動バックアップと手動バックアップはともにダウンロードをサポートしていません。 | データベースの binlog ログファイルのバックアップは、MySQL シングルノード（クラウドディスク）、デュアルノード、トリプルノード、クラウドストレージ版（クラウドディスク）をサポートします： ログファイルはインスタンスバックアップのスペースを占有します。 ログファイルはダウンロードをサポートしますが、圧縮はサポートしていません。 ログファイルの保存期間は設定できます。 |
注意事項
TencentDB for MySQLの自動バックアップは、2019年2月26日以降、物理バックアップのみをサポートします。自動バックアップ設定のデフォルト方式は物理バックアップとなり、論理バックアップは提供されなくなりました。既存の論理バックアップを使用しているインスタンスは、順次物理バックアップに自動的に切り替えられます。
この切り替えはビジネスアクセスに影響しませんが、自動バックアップの使用習慣に影響する可能性があります。論理バックアップが必要な場合は、TencentDB for MySQLコンソールの手動バックアップ機能またはAPI呼び出しにより論理バックアップを生成できます。
手動バックアップのデフォルト方式は論理バックアップです。もし構成変更前に行うフルバックアップで論理バックアップを選択した場合、構成変更に時間がかかる可能性があります。構成変更の時間を短縮したい場合は、変更前のフルバックアップで物理バックアップを選択することを推奨します。
インスタンスバックアップファイルはバックアップスペースを占有します。バックアップスペースを適切にご利用ください。無料割り当てを超えたバックアップスペースには料金が発生します。詳細はバックアップスペースの料金説明をご参照ください。
ビジネスのオフピーク時間帯にバックアップを行うことを推奨します。
必要なバックアップファイルが保存期間を超えて削除されるのを避けるため、必要なバックアップファイルを速やかにローカルにダウンロードしてください。
バックアップ中はDDL操作を禁止します。テーブルロックによるバックアップ失敗を避けるためです。
MySQL 読み取り専用インスタンスはデータベースのバックアップをサポートしていません。
インスタンスがクロスアベイラビリティーゾーン移行を完了した当日が、そのインスタンスの自動バックアップ周期と重なった場合、システムバックアップが追加で発生します。例えば：あるインスタンスが8月5日に自動バックアップを行う予定ですが、当日にクロスアベイラビリティーゾーン移行を行っている場合、システムは通常の自動バックアップに加えて、移行完了時に追加でバックアップを自動的にトリガーします。
MySQLデータの自動バックアップ
MySQLデータの自動バックアップ
自動バックアップを設定します。
1. MySQLコンソールにログインし、インスタンスリストでインスタンスIDをクリックして管理ページに進み、バックアップと復元＞自動バックアップ設定を選択します。
2. ポップアップ表示されるバックアップ設定ダイアログボックスで、各バックアップパラメータを選択し、OKをクリックします。パラメータの説明は以下の通りです：
説明：
ロールバック機能は、バックアップ周期とバックアップ保持日数内のデータバックアップ＋ログバックアップ（binlog）に基づいています。自動バックアップの頻度や保持日数を短縮すると、インスタンスデータのロールバック可能な時間範囲に影響を与える可能性があります。バックアップ設定を慎重にご検討ください。
例えば：バックアップ周期を月曜日と木曜日に設定し、保持日数を7日間とした場合、7日以内（データバックアップとログバックアップの実際の保存期間）の任意の時点にロールバックできます。
自動バックアップは手動で削除することはできませんが、バックアップの保持期間を設定可能です。期限が切れると自動的に削除されます。
データバックアップとログバックアップの保持日数を増やすと、追加のバックアップストレージ課金費用が発生する可能性があります。
ログバックアップの保持日数を短縮すると、インスタンスのデータロールバック周期に影響を与える可能性があります。
バックアップの復旧可能な時間は、現在時刻から最も遠い有効な物理バックアップまたはフル論理バックアップから計算されます。実際のビジネスニーズに基づいて、バックアップの保持期間を適切に設定することをお勧めします。
自動バックアップ設定では、データバックアップの設定は定期的な保持を有効化することをサポートしています。定期的な保持が有効化されていない設定は通常バックアップ設定と呼ばれます。以下、通常バックアップ設定と定期的なバックアップ設定を有効化のパラメータ説明をそれぞれ説明します。
通常バックアップ設定の説明
パラメータ | 説明 |
バックアップ開始時間 | デフォルトの時間：システムが自動的に割り当てるバックアップ開始時間の範囲（0:00～12:00）。 カスタム：バックアップ開始時間帯を任意に選択できます（例：02:00～06:00）。ビジネスのオフピーク時間帯に設定することを推奨します。* 説明： バックアップ開始時間は、バックアップタスクがスケジュールキューに入る時間に過ぎません。例えば、02:00～06:00を選択してバックアップを有効にすると、システムは02:00～06:00の時間範囲内のある時点でバックアップタスクを開始します。具体的な開始時間は、バックエンドのバックアップ戦略とバックアップシステムの状態によります。バックアップタスクがインスタンスの稼働に影響を与えないことを確保するために、バックアップタスクは待ち行列のために遅延して開始される可能性があります。 バックアップタスクの所要時間はデータ量に比例し、最長で24時間を超えることはありません。 |
データバックアップの保持期間 | MySQLデュアルノード、トリプルノード、クラウドディスク版のデータバックアップファイルは、7日間～1830日間保持可能で、デフォルトは7日間です。保持期間を過ぎたバックアップセットは自動的に削除されます。 MySQLシングルノード（クラウドディスク）のデータバックアップファイルは、7日間～30日間保持できます。デフォルトは7日間です。保持期間を過ぎたバックアップセットは自動的に削除されます。 |
バックアップ周期 | 設定ルール： 週単位で設定：デフォルトでは月曜日から日曜日までの7日間が選択されています。バックアップ時間をカスタムで選択できますが、データセキュリティを保証するために、週に少なくとも2回バックアップを設定してください。 月単位で設定：データセキュリティを保証するため、1ヶ月内の任意の連続する日付間隔は2日を超えることはできません。例えば、1日にバックアップを設定した場合、次回のバックアップ日は2日、3日、4日を飛ばして5日を選択することはできません。 説明： 月単位で設定する場合、連続して複数日バックアップが行われない状況を避けるため、以下の日付の組み合わせをスキップすることはできません：27/28/1（日）、28/29/1（日）、29/30/1（日）、28/1/2（日）、29/1/2（日）、30/1/2（日）。 |
バックアップのコールドストレージへの移行（オプション） | 対応するデータバックアップのコールドストレージ移行ポリシーを選択し、日数を指定してください： 指定した標準ストレージ日数：つまり、データバックアップファイルが生成されてから何日後に、標準ストレージへ移行するかを設定します。 指定したアーカイブストレージ日数：データバックアップファイルが生成されてから何日後に、アーカイブストレージへ移行するかを設定します。バックアップのコールドストレージへの移行に関する詳細な説明とポリシーについては、バックアップのコールドストレージへの移行設定を参照してください。なお、アーカイブストレージ機能は現在公開されていません。ぜひご期待ください。 説明： シングルノード（クラウドディスク）、クラウドディスク版インスタンスは現在バックアップのコールドストレージへの移行設定をサポートしていません。 |
ログバックアップの保持期間 | MySQLデュアルノード、トリプルノード、クラウドディスク版のログバックアップファイルは、7日間～3650日間保持可能で、デフォルトは7日間です。保持期間を過ぎたバックアップセットは自動的に削除されます。 MySQLシングルノード（クラウドストレージ）のログバックアップファイルは、7日間～30日間保持できます。デフォルトは7日間です。保持期間を過ぎたバックアップセットは自動的に削除されます。 |
バックアップのコールドストレージへの移行（オプション） | 対応するbinlogバックアップのコールドストレージ移行ポリシーを選択し、日数を指定してください： 指定した標準ストレージ日数： binlogファイルが生成されてから何日後に、標準ストレージへ移行するかを設定します。 指定したアーカイブストレージ日数：binlogファイルが生成されてから何日後に、アーカイブストレージへ移行するかを設定します。バックアップのコールドストレージへの移行に関する詳細な説明とポリシーについては、バックアップのコールドストレージへの移行設定をご参照ください。なお、アーカイブストレージ機能は現在準備中です。 説明： シングルノード（クラウドディスク）、クラウドディスク版インスタンスは現在バックアップのコールドストレージへの移行設定をサポートしていません。 |
*バックアップ開始時間の選択は、システムのスケジューリングリソースの制限を受ける可能性があります。設定中に特定の時間帯が選択不可であることに気付いた場合、その時間帯のバックアップキューが飽和状態にあることを示しています。他の空いている時間帯を選択して設定を完了することをお勧めします。
定期バックアップ設定の有効化に関する説明
定期バックアップ設定の有効化に関する説明
説明：
シングルノード（クラウドディスク）、クラウドディスク版インスタンスは、現在定期バックアップ設定機能をサポートしていません。
定期バックアップの保持期間は、通常のバックアップ設定の保持期間より長く設定する必要があります。
パラメータ | 説明 |
バックアップ開始時間 | デフォルトの時間：システムが自動的に割り当てるバックアップ開始時間の範囲（0:00～12:00）。 カスタム：バックアップ開始時間帯を任意に選択できます（例：02:00～06:00）。ビジネスのオフピーク時間帯に設定することを推奨します。 説明： バックアップ開始時間は、バックアップタスクがスケジュールキューに入る時間に過ぎません。例えば、02:00～06:00を選択してバックアップを有効にすると、システムは02:00～06:00の時間範囲内のある時点でバックアップタスクを開始します。具体的な開始時間は、バックエンドのバックアップ戦略とバックアップシステムの状態によります。バックアップタスクがインスタンスの稼働に影響を与えないことを確保するために、バックアップタスクは待ち行列のために遅延して開始される可能性があります。 バックアップタスクの所要時間はデータ量に比例し、最長で24時間を超えることはありません。 |
データバックアップの保持期間 | MySQLデュアルノード、トリプルノードのデータバックアップファイルは、7日間～1830日間保持可能で、デフォルトは7日間です。保持期間を過ぎたバックアップセットは自動的に削除されます。 |
バックアップ周期 | 設定ルール： 週単位で設定：デフォルトでは月曜日から日曜日までの7日間が選択されています。バックアップ時間をカスタムで選択できますが、データセキュリティを保証するために、週に少なくとも2回バックアップを設定してください。 月単位で設定：データセキュリティを保証するため、1ヶ月内の任意の連続する日付間隔は2日を超えることはできません。例えば、1日にバックアップを設定した場合、次回のバックアップ日は2日、3日、4日を飛ばして5日を選択することはできません。 説明： 月単位で設定する場合、連続して複数日バックアップが行われない状況を避けるため、以下の日付の組み合わせをスキップすることはできません：27/28/1（日）、28/29/1（日）、29/30/1（日）、28/1/2（日）、29/1/2（日）、30/1/2（日）。 |
定期的なバックアップの保持期間 | データバックアップファイルは90日～3650日間保持可能で、デフォルトは1080日間です。保持期間を過ぎたバックアップセットは自動的に削除されます。 |
定期的なバックアップ保持ポリシー | 月単位、四半期単位、または年単位でバックアップ保持数を設定することがサポートされています。 |
開始日 | 定期的なバックアップ保持の開始時間を実行します。 |
バックアップのコールドストレージへの移行（オプション） | 対応するデータバックアップのコールドストレージ移行ポリシーを選択し、日数を指定してください： 指定した標準ストレージ日数：つまり、データバックアップファイルが生成されてから何日後に、標準ストレージへ移行するかを設定します。 指定したアーカイブストレージ日数：データバックアップファイルが生成されてから何日後に、アーカイブストレージへ移行するかを設定します。バックアップのコールドストレージへの移行に関する詳細な説明とポリシーについては、バックアップのコールドストレージへの移行設定を参照してください。なお、アーカイブストレージ機能は現在公開されていません。ぜひご期待ください。 |
ログバックアップの保持期間 | ログバックアップファイルは7日～3650日間保持可能で、デフォルトは7日間です。保持期間を過ぎたバックアップセットは自動的に削除されます。 |
バックアップのコールドストレージへの移行（オプション） | 対応するbinlogバックアップのコールドストレージ移行ポリシーを選択し、日数を指定してください： 指定した標準ストレージ日数： binlogファイルが生成されてから何日後に、標準ストレージへ移行するかを設定します。 指定したアーカイブストレージ日数：binlogファイルが生成されてから何日後に、アーカイブストレージへ移行するかを設定します。バックアップのコールドストレージへの移行に関する詳細な説明とポリシーについては、バックアップのコールドストレージへの移行設定をご参照ください。なお、アーカイブストレージ機能は現在公開されていません。ぜひご期待ください。 |
保持プランを確認します
説明：
シングルノード（クラウドディスク）、クラウドディスク版インスタンスは、現在保持プランの表示機能をサポートしていません。
バックアップ設定で定期バックアップ保持ポリシーを選択した後、保持プランを表示をクリックしてプレビューできます。
ブルーの日付は、通常のバックアップが実行される日付を示します。
赤い日付は、定期バックアップが実行される日付を示します。
通常のバックアップまたは定期バックアップをクリックして、対応する日付の色付けを非表示にし、プレビューしやすくします。
バックアップ計画のプレビューは、今後1年間のバックアップ保持状況を一時的に表示するものであり、参考としてのみ提供されます。
MySQLデータを手動バックアップ
MySQLデータを手動バックアップ
手動バックアップ機能は、ユーザーが自分でバックアップタスクを開始することを可能にします。
説明：
MySQLデュアルノードおよびトリプルノードインスタンスの手動バックアップは、フル物理バックアップ、フル論理バックアップ、および単一データベース・単一テーブルの論理バックアップをサポートします。
MySQLデュアルノードおよびトリプルノードインスタンスの手動バックアップは、バックアップリストから手動で削除可能です。これによりバックアップ領域を解放し、領域の浪費や占有を回避できます。手動削除が行われない限り、データベースインスタンスの提供が終了するまで保持されます。
MySQLシングルノード（クラウドディスク）インスタンスの手動バックアップは、フルスナップショットバックアップをサポートします。
MySQLシングルノード（クラウドディスク）インスタンスの手動バックアップは、削除はサポートされていません。
インスタンスは、毎日の自動バックアップタスクの実行期間中、手動バックアップを開始できません。
手動バックアップは、最も高い優先度でバックアップキューに入ります。具体的な開始時間は、バックアップリストのタスク開始時刻フィールドでご確認ください。
1. MySQLコンソールにログインし、インスタンスリストでインスタンスIDをクリックして管理ページに進み、バックアップと復元 > 手動バックアップを選択します。
2. ポップアップ表示されるバックアップ設定ダイアログボックスで、バックアップ方法と対象を選択し、備考名を入力して、OKをクリックします。
説明：
論理バックアップで単一データベースまたは単一テーブルをバックアップする場合、左側のデータベース・テーブルを選択で対象のデータベースまたはテーブルをチェックを入れ、右側のリストに追加してください。データベースまたはテーブルがない場合は、先にデータベースまたはテーブルを作成してください。
手動バックアップのデフォルト方式は論理バックアップです。もし構成変更前に行うフルバックアップで論理バックアップを選択した場合、構成変更に時間がかかる可能性があります。構成変更の時間を短縮したい場合は、変更前のフルバックアップで物理バックアップを選択することを推奨します。
1. MySQLコンソールにログインし、インスタンス一覧でターゲットインスタンスIDをクリックして管理ページに進み、バックアップと復元 > 手動バックアップを選択します。
2. 備考名を入力し、OKをクリックします。
バックアップのデータ保護
改ざん防止
TencentDB for MySQLのバックアップシステムは二重モードでバックアップデータを保存します：フル物理バックアップ、フル論理バックアップ、およびログバックアップはCOSに保存され、フルスナップショットバックアップはクラウドストレージスナップショットサービスに保存されます。両方式ともWORM（write once read many）の改ざん不可能特性を備えています。
悪意削除／誤削除防止
ユーザーによる手動削除：ユーザーが手動バックアップデータ（手動論理バックアップ、手動物理バックアップ）を削除することを許可しますが、自動バックアップデータの削除は許可されません（詳細はバックアップの削除を参照してください）。
自動バックアップの期限切れ削除：自動バックアップデータは期限切れ後に自動削除されますが、同時に自動バックアップを無効にできない制限があります。バックアップ保持期間は最低7日間、週次バックアップ回数は最低2回です（詳細はMySQLデータの自動バックアップを参照してください）。したがってユーザーの自動バックアップで生成されたフルデータとログデータは完全に削除できません。
ホットトピック
バックアップの保持期間を超えたバックアップはダウンロードまたは復元が可能かどうか。
期限切れのバックアップセットは自動的に削除され、ダウンロードや復元はできなくなります。
ニーズに応じてバックアップの保持期間を適切に設定するか、MySQLコンソールでバックアップファイルをローカルにダウンロードすることをお勧めします（シングルノードクラウドディスクインスタンスのバックアップファイルは現在ダウンロードをサポートしていないことにご注意ください）。
コンソールで手動バックアップによりインスタンスデータをバックアップすることもでき、手動バックアップは永久に保存されます。
説明：
手動バックアップもバックアップスペースを占有します。追加費用が発生しないように、バックアップスペースを適切に使用してください。
2. バックアップは手動で削除できますか。
自動バックアップは手動で削除できませんが、バックアップの保持期間を設定可能です。期限が切れると自動的に削除されます。
デュアルノードおよびトリプルノードインスタンスの手動バックアップは、MySQLコンソールのバックアップリストから手動で削除できます。手動削除が行われない限り保持され続けますが、シングルノードクラウドディスクインスタンスの手動バックアップは現在削除をサポートしていません。
データとログバックアップを無効にできるかどうか。
無効にできません。ただし、MySQLコンソールを通じてバックアップ頻度を減らしたり、使用しなくなった手動バックアップデータを削除したりすることで、バックアップスペースの使用量を減らすことができます（シングルノードクラウドディスクインスタンスの手動バックアップは現在削除をサポートしていません）。
4. バックアップスペースの消費を削減する方法。
使用しなくなった手動バックアップデータを削除します（手動バックアップは、MySQLコンソールのインスタンス管理ページ > バックアップと復元ページで削除できます。ご注意ください、シングルノードクラウドディスクインスタンスの手動バックアップは現在削除をサポートしていません）。
コアではないビジネスのデータ自動バックアップ頻度を下げることができます（コンソールでバックアップ周期とバックアップの保持期間を調整でき、週に少なくとも2回バックアップします）。
説明：
ロールバック機能は、バックアップ周期とバックアップ保持日数内のデータバックアップ＋ログバックアップ（binlog）に基づいています。自動バックアップの頻度や保持日数を短縮すると、インスタンスデータのロールバック可能な時間範囲に影響を与える可能性があります。バックアップ設定を慎重にご検討ください。
コアではないビジネスのデータバックアップとログバックアップの保存期間を短縮します（バックアップの保持期間が7日間であれば、ほとんどのシナリオの必要を満たすことができます）。
バックアップのコールドストレージへの移行を設定し、カスタムのバックアップコールドストレージ移行ポリシーを定義することで、バックアップファイルのストレージタイプを変換し、ストレージコストを削減できます。
業務シナリオ | バックアップの保持期間 |
コアビジネス | バックアップの保持期間を7日～3650日間に設定することをお勧めします。定期的なバックアップを有効化し、長期的な保存を実現することを推奨します。 |
非コア、非データ関連ビジネス | 7日間を推奨します。 |
アーカイブビジネス | データバックアップの保持期間を7日に設定することをお勧めします。実際の業務ニーズに基づいてデータを手動でバックアップし、使用後は速やかに削除してください。 |
テストビジネス | データバックアップの保持期間を7日に設定することをお勧めします。実際の業務ニーズに基づいてデータを手動でバックアップし、使用後は速やかに削除してください。 |
フィードバック