製品アップデート情報一覧
データベースのバックアップ
データを喪失または破損させないために、自動バックアップまたは手動バックアップによってデータベースをバックアップできます。
バックアップの概要
バックアップモード
TencentDB for MySQLシングルノード（クラウドディスク）、デュアルノード（ローカルディスク）、トリプルノード（ローカルディスク）、クラウドディスク版（クラウドディスク）は、自動バックアップと手動バックアップの2つの方法でデータベースをバックアップできます。
バックアップタイプ
TencentDB for MySQLの2ノード、3ノードは次の2種類のバックアップタイプに対応します：
物理バックアップ：物理データを完全コピーすることです（自動バックアップと手動バックアップの両方でサポート）。
論理バックアップ：SQLステートメントをバックアップすることです（手動バックアップへのサポート）。
説明：
物理バックアップを使用してデータベースを復元するには、xbstreamを利用してパッケージを解凍する必要があります。詳細については、物理バックアップでデータベースを復元するをご参照ください。
1つのインスタンスにおけるテーブル数が30万を超えると、バックアップに失敗する可能性があります。また、データベース監視にも影響を及ぼすため、テーブル数を適切に管理し、1インスタンスあたり30万テーブル以下に抑えてください。
バックアップ時間は、データベースのデータファイルのサイズおよびテーブル数に比例します。データファイルが大きい、またはテーブル数が多いほど、バックアップ時間は長くなります。
Memoryエンジンテーブルのデータがメモリに格納されているので、Memoryエンジンテーブルの物理バックアップを実行できません。データの紛失を避けるために、MemoryエンジンテーブルをInnoDBテーブルに置き換えることをお勧めします。
インスタンスにはプライマリキーのないテーブルが多数存在するため、バックアップに失敗し、インスタンスの高可用性に影響を与える可能性があります。プライマリキーのないテーブルのプライマリキーまたはセカンダリインデックスを適時に作成してください。
手動バックアップ > 論理バックアップ操作を行うとグローバルリードロックが発生します。コンソール経由でこの操作は行うことを推奨します（コンソールからの論理バックアップはスレーブインスタンスに対して行われるため、マスターインスタンスには影響しません）。
物理バックアップのメリット | 論理バックアップのデメリット |
バックアップ速度が速いです。 ストリーミングバックアップと圧縮をサポートします。 バックアップの成功率が高いです。 復元は簡単で効率的です。 バックアップとの結合作業、例えば、ROの増加、災害復旧の増加で速度がより速くなります。 物理バックアップにかかる平均時間は論理バックアップの1/8程度です。 物理バックアップのインポート速度は論理バックアップより10倍ほど速いです。 | 復元するにはSQLの実行とインデックスの作成が必要なので、かかる時間が長くなります。 バックアップ速度が遅いです。大量のデータがある場合は特に速度が低下します。 バックアッププロセスは、インスタンスに負荷をかけ、マスター/スレーブの遅延を大きくする可能性があります。 単精度浮動小数点数の精度情報が紛失する可能性があります。 各種エラー（エラービューなど）によって、バックアップの失敗になる可能性があります。 バックアップとの結合作業、例えば、ROの増加、災害復旧の増加で速度が遅くなる可能性があります。 |
TencentDB for MySQLシングルノード（クラウドディスク）、クラウドディスク版（クラウドディスク）****はスナップショットバックアップに対応しています。
スナップショットバックアップ：ストレージ階層のディスクのスナップショットを作成してバックアップします（自動バックアップと手動バックアップの両方がサポートされます）。
説明：
シングルノード（クラウドディスク）インスタンスは単一ノード構成のため、バックアップはマスターノード上で実行されます。バックアップを行う際は、ビジネスのオフピーク時間帯に操作することを推奨します。
スナップショットバックアップのメリット | スナップショットバックアップのデメリット |
バックアップ速度が速いです。 使用する容量が比較的小さいです。 | ダウンロードをサポートしていません。 |
バックアップのオブジェクト
データバックアップ | ログバックアップ |
MySQL 2ノード、3ノード： 自動バックアップは全データの物理バックアップをサポートしています。 手動バックアップは全データの物理バックアップ、全データの論理バックアップと単一データベース、単一テーブルの論理バックアップをサポートしています。 自動バックアップと手動バックアップの両方とも圧縮とダウンロードをサポートしています。 MySQLシングルノード（クラウドディスク）、クラウドディスク版（クラウドディスク）： 自動バックアップは全データのスナップショットバックアップをサポートしています。 手動バックアップは全データのスナップショットバックアップをサポートしています。 自動バックアップと手動バックアップの両方ともダウンロードをサポートしていません。 | データベースのbinlogログファイルのバックアップは、MySQLシングルノード（クラウドディスク）、デュアルノード、トリプルノード、クラウドディスク版（クラウドディスク）でサポートされています： ログファイルはインスタンスバックアップの容量を使用します。 ログファイルはダウンロードをサポートしていますが、圧縮をサポートしていません。 ログファイルの保存期間を設定できます。 |
注意事項
MySQLの自動バックアップ機能は、2019年02月26日より、物理バックアップのみサポートされています。自動バックアップは、デフォルトで物理バックアップに設定され、論理バックアップを提供されなくなりました。既存の自動論理バックアップは、自動的に物理バックアップに切り替えられます。
この切り替え作業は、サービスへのアクセスに影響を与えませんが、自動バックアップを使う習慣のある方に若干の影響を与える可能性があります。論理バックアップを実行したい場合、 MySQLコンソール の手動バックアップ方法、或いはAPIの呼び出しで論理バックアップを生成することができます。
手動バックアップのデフォルト方式は論理バックアップです。もし構成変更前に行うフルバックアップで論理バックアップを選択した場合、構成変更に時間がかかる可能性があります。構成変更の時間を短縮したい場合は、変更前のフルバックアップで物理バックアップを選択することを推奨します。
インスタンスバックアップファイル占用バックアップキャパシティについては、バックアップキャパシティを適切に使用してください。バックアップキャパシティが無料制限を超えたものには課金されます。 バックアップスペース課金説明をご参照ください。
サービス量の少ない時期にデータベースをバックアップすることをお勧めします。
一定の保持期間を過ぎた場合、ファイルが自動的に削除されますので、必要なバックアップファイルをローカルにダウンロードしてください。
テーブルロックによるバックアップの失敗を回避するために、バックアップ中は、DDL操作をしないでください。
単一ノードのMySQLインスタンスはデータベースのバックアップをサポートしていません。
インスタンスがクロスアベイラビリティーゾーン移行を完了した当日が、そのインスタンスの自動バックアップ期間と重なった場合、システムは追加でバックアップを一度実行します。例えば、あるインスタンスが8月5日に自動バックアップを予定していても、同日にクロスアベイラビリティーゾーン移行を行った場合、システムは通常の自動バックアップに加えて、移行完了時にもう一度バックアップを自動的に実行します。
MySQLデータの自動バックアップ
MySQLデータの自動バックアップ
自動バックアップの設定
1. MySQLコンソールにログインし、インスタンスリストのページでインスタンスIDをクリックすると、管理ページに進み、バックアップと復元 > 自動バックアップの設定を選択します。
2. バックアップ設定のためのポップアップダイアログで、バックアップパラメータを選択し、OKをクリックします。パラメータは次のように説明されています：
説明：
ロールバック機能 は、バックアップサイクルとバックアップ保持日数内のデータバックアップ + ログバックアップ（binlog）を基準にしています。自動バックアップ頻度と保持日数を短縮すると、インスタンスデータのロールバック期間の範囲に影響します。バックアップの設定は十分に検討してください。
例えば、バックアップサイクルを月曜と木曜、保持日数を7日間に設定すると、7日以内（データバックアップとログの有効バックアップの実際の保存期間）の任意の時点でロールバックできます。
自動バックアップしたものは手動で削除することはできませんが、バックアップ保持期間を設定して、期限がきたら自動削除することができます。
データバックアップとログバックアップの保持日数を追加すると予定外のバックアップキャパシティ費用が生じる恐れがあります。
ログバックアップの保持日数を短縮するとインスタンスのデータロールバックサイクルに影響する恐れがあります。
自動バックアップ設定では、データバックアップの設定について定期保持を有効にすることをサポートしています。定期保持を有効にしていない設定は通常バックアップ設定と呼ばれます。以下では、通常バックアップ設定および定期バックアップ設定を有効にするの各パラメータについて説明します。
通常バックアップの設定説明
パラメータ | 説明 |
バックアップ開始時間 | 例えば、02:00～06:00時を選択した場合、システムは、02:00～06:00の時間帯にある特定の時刻にバックアップを開始します。具体的な開始時刻は、バックエンドのバックアップポリシーとバックアップシステム状況に依存します。 デフォルト時間：システムが自動的に割り当てるバックアップ開始時間帯（0:00～12:00）。 カスタム：バックアップ開始時間帯を任意に選択できます（例：02:00～06:00）。ビジネスのオフピーク時間帯に設定することを推奨します。 説明： - バックアップ開始時間は、あくまでバックアップタスクがスケジュールキューに入る時間です。例えば、02:00～06:00を選択した場合、システムはこの時間帯のいずれかの時点でバックアップタスクを開始します。具体的な開始時間は、バックエンドのバックアップ戦略とシステムの状態によって決まります。インスタンスの稼働に影響を与えないよう、キューの状況によりタスクの開始が遅延することがあります。 - バックアップタスクの所要時間はデータ量に比例し、最長で24時間を超えることはありません。 |
データバックアップの保存時間 | MySQL 2ノード、3ノードのデータバックアップファイルは7日～1830日保存可能で、デフォルトで7日間保存されます。期限を過ぎると、バックアップセットは自動削除されます。 MySQL単一ノード（クラウドディスク）のデータバックアップファイルは7日～1830日保存可能で、デフォルトで7日間保存されます。期限を過ぎると、バックアップセットは自動削除されます。 |
バックアップサイクル | 設定ルール： 週ごとの設定：デフォルトでは月曜日から日曜日までの7日間が選択され、バックアップ時刻のカスタマイズをサポートしています。ただし、データの安全性を確保するために、週に2回以上バックアップするように設定してください。 月ごとの設定：データを安全に保つため、1か月のうち、隣接する2つの日付の間隔は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日～1830日保存可能で、デフォルトで7日間保存されます。期限を過ぎると、バックアップセットは自動削除されます。 |
コールドバックアップへのダウングレード（オプション） | 適切なbinlogコールドバックアップへのダウングレードポリシーを選択し、日数を指定します： 指定した標準ストレージ日数： binlogファイルが生成されてから何日後に、標準ストレージへ移行するかを設定します。 指定したアーカイブストレージ日数：binlogファイルが生成されてから何日後に、アーカイブストレージへ移行するかを設定します。バックアップのコールドストレージへの移行に関する詳細な説明とポリシーについては、バックアップのコールドストレージへの移行設定をご参照ください。なお、アーカイブストレージ機能は現在準備中です。 説明： シングルノード（クラウドディスク）、クラウドディスクインスタンスは、現在バックアップのコールドストレージへの移行の設定をサポートしていません。 |
定期バックアップ設定を有効化する説明
定期バックアップ設定を有効化する説明
説明：
シングルノード（クラウドディスク）、クラウドディスク版インスタンスは、現在定期バックアップ設定機能をサポートしていません。
定期バックアップの保持時間は設定された通常バックアップ保持時間よりも長くしてください。
パラメータ | 説明 |
バックアップ開始時間 | デフォルト時間：システムが自動的に割り当てるバックアップ開始時間帯（0:00～12:00）。 カスタム：バックアップ開始時間帯を任意に選択できます（例：02:00～06:00）。ビジネスのオフピーク時間帯に設定することを推奨します。 説明： - バックアップ開始時間は、あくまでバックアップタスクがスケジュールキューに入る時間です。例えば、02:00～06:00を選択した場合、システムはこの時間帯のいずれかの時点でバックアップタスクを開始します。具体的な開始時間は、バックエンドのバックアップ戦略とシステムの状態によって決まります。インスタンスの稼働に影響を与えないよう、キューの状況によりタスクの開始が遅延することがあります。 - バックアップタスクの所要時間はデータ量に比例し、最長で24時間を超えることはありません。 |
データバックアップの保持時間 | MySQLの2ノード・3ノードデータバックアップファイルは7日～1830日保持でき、デフォルト値は7日です。期限がきたらバックアップセットは自動削除されます。 |
バックアップサイクル | 設定ルール： 週ごとの設定：デフォルトでは月曜日から日曜日までの7日間が選択され、バックアップ時刻のカスタマイズをサポートしています。ただし、データの安全性を確保するために、週に2回以上バックアップするように設定してください。 月ごとの設定：データを安全に保つため、1か月のうち、隣接する2つの日付の間隔は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日～1830日保持でき、デフォルト値は7日です。期限がきたらバックアップセットは自動削除されます。 |
コールドバックアップへのダウングレード（オプション） | 適切なbinlogコールドバックアップへのダウングレードポリシーを選択し、日数を指定します： 標準ストレージ日数を指定します。つまり、binlogファイルが生成された日から標準ストレージにダウングレードするまでの経過日数を設定します。 アーカイブストレージ日数の指定：binlogファイルが生成された日からアーカイブストレージにダウングレードするまでの経過日数を設定します。
コールドバックアップへのダウングレード手順とポリシーの詳細については、コールドバックアップへのダウングレード設定をご参照ください。このうち、アーカイブストレージ機能は現在オープンではありませんので、しばらくお待ちください。 |
保持計画の確認
説明：
シングルノード（クラウドディスク）、クラウドディスク版インスタンスは、現在保持プランの表示機能をサポートしていません。
バックアップ設定で定期バックアップ保持ポリシーを選択した後、保持計画を確認をクリックしてプレビューが表示されます。
青い日付は通常バックアップの期日を意味します。
赤い日付は定期バックアップの期日を意味します。
通常バックアップまたは定期バックアップをクリックして、プレビューのため、対応する日付の色分けを非表示します。
バックアップ計画のプレビューは今後1年間のバックアップ保持状況であり、参考用です。
MySQLデータの手動バックアップ
MySQLデータの手動バックアップ
手動バックアップ機能を使用すると、バックアップタスクを手動で開始できます。
説明：
MySQL 2ノード、3ノードのインスタンスの手動バックアップは、全データの物理バックアップ、全データの論理バックアップ、および単一データベース、単一テーブルの論理バックアップをサポートしています。
MySQL 2ノード、3ノードのインスタンスの手動バックアップをバックアップリストで手動で削除することで、バックアップ容量をリリースして、容量の浪費と不必要な使用を回避できます。手動で削除しない限り、データベースインスタンスがオフラインになるまで保存されます。
MySQL単一ノード（クラウドディスク）のインスタンスは全データのスナップショットバックアップをサポートしています。
MySQL単一ノード（クラウドディスク）のインスタンスの手動バックアップは削除をサポートしていません。
インスタンスは毎日の自動バックアップタスクを実行する期間内に手動バックアップを開始することができません。
手動バックアップは、最も高い優先度でバックアップキューに入ります。具体的な開始時間は、バックアップリストのタスク開始時刻フィールドでご確認ください。
1. MySQLコンソールにログインし、インスタンス一覧で対象のインスタンスIDをクリックして管理画面に移動し、バックアップと復元 > 手動バックアップを選択します。
2. ポップアップした設定ダイアログで、バックアップ方法と対象を選択し、備考名を入力して、確定をクリックします。
説明：
論理バックアップで単一データベースまたは単一テーブルをバックアップする場合、左側のデータベース・テーブルを選択で対象のデータベースまたはテーブルをチェックを入れ、右側のリストに追加してください。データベースまたはテーブルがない場合は、先にデータベースまたはテーブルを作成してください。
手動バックアップのデフォルト方式は論理バックアップです。もし構成変更前に行うフルバックアップで論理バックアップを選択した場合、構成変更に時間がかかる可能性があります。構成変更の時間を短縮したい場合は、変更前のフルバックアップで物理バックアップを選択することを推奨します。
1. MySQLコンソールにログインし、インスタンス一覧で対象のインスタンスIDをクリックして管理画面に移動し、バックアップと復元 > 手動バックアップを選択します。
2. 備考名を入力し、確定をクリックします。
よくあるご質問
1. バックアップ保持期間が過ぎたバックアップは、まだダウンロードや元に戻すことができますか？
期限切れのバックアップセットは自動的に削除され、ダウンロードまたは復元できません。
必要に応じてバックアップ保存時間を適切に設定する、またはMySQLコンソールでバックアップファイルをデバイス内にダウンロードすることをお勧めします（注意：単一ノードのクラウドディスクインスタンスのバックアップファイルは、現在ダウンロードをサポートしていません）。
コンソールでインスタンスデータを手動でバックアップすることもでき、手動バックアップは永続的に保持されます。
説明：
手動バックアップは、バックアップキャパシティを占用することもあります。バックアップキャパシティを適切に使用して、予定外の費用が生じないようにしてください。
2. バックアップは手動で削除できますか？
自動バックアップしたものは手動で削除することはできませんが、バックアップ保持期間を設定して、期限がきたら自動削除することができます。
2ノード、3ノードのインスタンスの手動バックアップは、MySQLコンソールのバックアップリストから手動で削除できます。手動で削除しない限り、バックアップは永久に保存されます。単一ノードのクラウドディスクインスタンスの手動バックアップは、現在削除をサポートしていません。
3. データとログのバックアップは停止できますか？
無効にできません。ただし、MySQLコンソールからバックアップ頻度を削減し、今後使用しない手動バックアップデータを削除することで、バックアップ容量の使用量を削減することができます（単一ノードのクラウドディスクインスタンスの手動バックアップは、現在削除をサポートしていません）。
4. どのようにしてバックアップキャパシティのオーバーヘッドを減らしますか？
今後使用しない手動バックアップデータを削除します（手動バックアップはMySQLコンソールのインスタンス管理ページ > バックアップ復元ページで削除できます。注意：単一ノードのクラウドディスクインスタンスの手動バックアップは、現在削除をサポートしていません）。
非コアビジネスのデータの自動バックアップ頻度を減らします（コンソールでバックアップ周期とバックアップ保留時間を調整することができ、1週間に少なくとも2回バックアップします）。
説明：
ロールバック機能 は、バックアップサイクルとバックアップ保持日数内のデータバックアップ+ ログバックアップ（binlog）を基準にしています。自動バックアップ頻度と保持日数を短縮すると、インスタンスデータのロールバック期間の範囲に影響します。バックアップの設定は十分に検討してください。
非コアビジネスのデータバックアップおよびログバックアップの保存時間を短縮します(7日間のバックアップ保留時間は、既に大部分のシナリオの要件を満たすことができます)。
コールドバックアップへのダウングレードの設定でコールドバックアップへのダウングレードポリシーを設定し、バックアップファイルのストレージタイプを変換し、ストレージコストを削減させます。
サービスケース | バックアップ保留時間 |
コアビジネス | 7日～3650日はおすすめです。バックアップの長期保存のために定期バックアップを有効にすることをおすすめします |
中核でない、データ類でないサービス | 7日をお勧めします |
アーカイブ類サービス | バックアップの保留時間を7日間とし、実際のサービスニーズにより手動でデータをバックアップし、使い終わったら適時に削除することをお勧めします |
テスト類サービス | バックアップの保留時間を7日間とし、実際のサービスニーズにより手動でデータをバックアップし、使い終わったら適時に削除することをお勧めします |
フィードバック