PolarDB:バックアップと復元のよくある質問

PolarDB のバックアップは、各バックアップの 論理サイズ とすべてのバックアップの 物理サイズ という 2 つのメトリクスで測定されます。

• 論理サイズ：一貫性のあるスナップショット時点 でのデータ量 (データとログ) です。

• 物理サイズ：バックアップのスナップショットチェーンのサイズです。PolarDB は、バックアップに増分スナップショットチェーンメカニズムを使用します。このメカニズムは、各時点でのスナップショットの状態を保持します。データブロックが変更されると、システムはスナップショット用にデータブロックの履歴バージョンを保持します。データは、以前のスナップショットの有効期限が切れた場合にのみ、スナップショットチェーンから削除されます。

  例：クラスターのデータ量が 100 GB であると仮定します。レベル 1 バックアップ/データバックアップのバックアップサイクルは 1 日に 1 回で、保持期間は 3 日間です。

  日付	データ変更プロセス	ストレージ内のデータサイズ	対応するスナップショットチェーン (物理バックアップ) のサイズ
  月曜日	100 GB のデータを追加	100 GB + 100 GB = 200 GB	+ 0 GB = 0 GB 説明 これは、月曜日より前のスナップショットチェーン (物理バックアップ) のサイズを考慮していません。 実際のシナリオでは、増分は 0 GB ではありません。スナップショットによって参照されるデータブロックが完全に書き込まれていない場合があります。これらのデータブロックに新しいデータを書き込む必要がある場合、データブロックの新しいコピーが作成されます。したがって、スナップショットを作成した後にデータを書き込むと、スナップショットチェーン (物理バックアップ) のサイズも増加します。
  火曜日	1 GB のデータを変更し、1 GB のデータを追加	200 GB + 1 GB = 201 GB	0 GB + 1 GB = 1 GB
  水曜日	100 GB のデータを削除 説明 削除されたデータは、月曜日に追加されたデータです。	201 GB - 100 GB = 101 GB	1 GB + 100 GB = 101 GB
  木曜日	1 GB のデータを変更し、1 GB のデータを追加	101 GB + 1 GB = 102 GB	101 GB + 1 GB = 102 GB
  金曜日	1 GB のデータを変更し、1 GB のデータを追加	102 GB + 1 GB = 103 GB	102 GB + 1 GB = 103 GB 説明 この時点で、月曜日のスナップショットの有効期限が切れています。ただし、スナップショットチェーン (物理バックアップ) のサイズは減少しません。システムは、火曜日のバックアップセットのデータブロックの履歴バージョンを引き続き保持します。
  土曜日	1 GB のデータを変更し、1 GB のデータを追加	103 GB + 1 GB = 104 GB	103 GB + 1 GB - 100 GB = 4 GB 説明 この時点で、火曜日のスナップショットの有効期限が切れています。システムは、月曜日に追加され、水曜日に削除されたデータのデータブロックの履歴バージョンを保持する必要がなくなります。したがって、スナップショットチェーン (物理バックアップ) のサイズは 100 GB 減少します。

  説明

  • 上記の例は参考用です。クラスター内のビジネスデータのみを考慮しており、システムファイルは含まれていません。実際のサイズは異なる場合があります。

  • データブロックの変更頻度を変えずに物理バックアップサイズを削減するには、バックアップサイクルと保持期間を短縮します。詳細については、「レベル 1、レベル 2、ログバックアップのデータ量とコストを削減する方法」をご参照ください。

いいえ。物理サイズは、バックアップの種類によって意味する指標が異なります。

PolarDB のバックアップには、各バックアップセットの論理サイズとすべてのバックアップの物理サイズという 2 つのサイズメトリクスがあります。PolarDB はバックアップにスナップショットチェーンメカニズムを使用しており、各一意のデータブロックは 1 回のみ保存されます。したがって、合計の物理サイズは論理サイズの合計よりも小さくなり、単一のバックアップの論理サイズよりも小さくなることがあります。

レベル 1 バックアップ/データバックアップ、レベル 2 バックアップ、およびログバックアップによって使用されるストレージスペースに対して課金されます。レベル 1 バックアップ/データバックアップとログバックアップはデフォルトで有効になっており、無料クォータが利用できます。レベル 2 バックアップはデフォルトで無効になっています。詳細については、「バックアップストレージ (無料クォータを超えた使用量に対して課金)」をご参照ください。

バックアップストレージの費用は、クラスターのストレージタイプによって異なります。

• Enterprise SSD (PL0、PL1、PL2、PL3、および AutoPL)

  • 計算式：1 時間あたりのコスト = (合計データバックアップサイズ - 無料クォータ) × 時間単価

  • 無料クォータ：ストレージ容量 × 50%

  例：中国本土で、合計データバックアップサイズが 700 GB、データベースストレージ使用量が 1,000 GB の場合、1 時間あたりのコストは[700 GB - (1,000 GB × 50%)] × 0.00003231 USD/GB/時間 = 0.006462 USD/時間です。詳細については、「バックアップストレージ (無料クォータを超えた使用量に対して課金)」をご参照ください。

• PSL4/PSL5

  • 計算式：1 時間あたりのコスト = (合計レベル 1 バックアップサイズ - 無料クォータ) × 時間単価

  • 無料クォータ： 無料クォータの計算式は、ストレージ課金方法によって異なります。計算式は次のとおりです。

    • サブスクリプション (購入容量ベース)：ストレージ容量 × 50%。

    • 従量課金 (使用量ベース)：ストレージ使用量 × 50%。

  例：中国本土の PSL5 ストレージクラスで、合計レベル 1 バックアップ (スナップショット) サイズが 700 GB、データベースストレージ使用量が 1,000 GB の場合、1 時間あたりのコストは[700 GB - (1,000 GB × 50%)] × 0.000464 USD/GB/時間 = 0.0928 USD/時間です。詳細については、「バックアップストレージ (無料クォータを超えた使用量に対して課金)」をご参照ください。

• 必要に応じて、バックアップデータの保持期間を短縮します。詳細については、「バックアップポリシーの設定」をご参照ください。

  • レベル 1 バックアップの保持期間を短縮します (例：7 日間から 3 日間)。

  • レベル 2 バックアップの保持期間を短縮します (例：70 日間から 30 日間)。

    説明

    レベル 1 およびレベル 2 バックアップの保持期間を短縮すると、リスクが伴います。必要なバックアップセットが保持期間よりも古い場合、それを使用してデータを復元することはできません。

  • ログバックアップの保持期間を短縮します (例：7 日間から 3 日間)。

    説明

    ログバックアップの保持期間を短縮すると、リスクが伴います。保持されている最も古いログバックアップよりも前の時点にポイントインタイムリストアを実行することはできません。

• 必要に応じて、バックアップ頻度 (バックアップサイクル) を減らします。詳細については、「バックアップポリシーの設定」をご参照ください。

  • レベル 1 バックアップの頻度を減らします (例：1 日 1 回から週 3 回)。

    説明

    レベル 1 バックアップの頻度を減らすと、ポイントインタイムリストアに必要な時間が増加する可能性があります。

  • レベル 2 バックアップの頻度を減らします (例：週 3 回から週 2 回)。

• クラスターごみ箱から不要なバックアップセットを削除して、レベル 2 バックアップのコストを削減します。詳細については、「バックアップの削除」をご参照ください。

はい。

手動バックアップファイルの保持期間は、バックアップポリシー設定 の バックアップデータ にある レベル 1 バックアップ または レベル 2 バックアップ に設定した データバックアップの保持期間 によって決まります。

レベル 2 バックアップのサイズは、データバックアップ タブで確認できます。このタブにアクセスするには、コンソールの設定と管理 > バックアップと復元ページに移動します。

[バックアップセット] タブの [バックアップサイズ] 列には、各バックアップレコードのサイズ (例：30.53 MB または 22.50 MB) が表示されます。ページの上部には、レベル 1 バックアップ (スナップショット) の合計サイズと無料クォータも表示されます。

クラスターを解放するときにバックアップセットを保持することを選択した場合、それらはPolarDBコンソールのクラスターごみ箱で確認できます。詳細については、「クラスターごみ箱」をご参照ください。

バックアップファイルをダウンロードしてコンピューターに保存できます。ただし、ダウンロードしたバックアップデータを直接使用してPolarDB for MySQL クラスターを復元することはできません。ダウンロードしたバックアップデータを使用して、バックアップファイルからセルフマネージド MySQL データベースにデータを復元することはできます。

次のいずれかの方法を使用して、PolarDB for MySQL のバックアップファイルを OSS に長期アーカイブできます。

• Alibaba Cloud Database Backup Service (DBS) を使用して、PolarDB for MySQL のバックアップファイルを OSS に保存します。次の手順を実行します。

  1. OSS コンソールで、バケットを作成します。

  2. PolarDB for MySQL の論理バックアップスケジュールを手動で設定します。バックアップが完了したら、バックアップセットを管理できます。たとえば、バックアップセットのクエリやバックアップセットのダウンロードが可能です。

• mysqldump または Data Management (DMS) を使用してバックアップファイルをエクスポートし、OSS にアップロードします。次の手順を実行します。

  1. mysqldump またはDMS を使用して、PolarDB for MySQL のバックアップファイルをエクスポートします。

  2. エクスポートしたバックアップファイルを手動で OSS にアップロードします。詳細については、「ファイルのアップロード」をご参照ください。

現在、本製品ではバックアップ失敗のアラートを直接設定することはできません。ただし、独自のアラートメカニズムを実装することは可能です。たとえば、定期的にDescribeBackups API を呼び出してバックアップジョブのBackupStatus フィールドを取得します。その後、そのステータスを確認し、ステータスが Failed の場合に、メール、SMS、または監視プラットフォームでの通知などのカスタムアラートをトリガーできます。

PolarDB クラスターの物理ログは redo ログです。各 redo ログファイルのサイズは 1 GB に固定されています。バックアップは、1 GB のファイルが完全に書き込まれた後にのみトリガーされます。クラスターが最近作成されたか、アクセス量が少ない場合、1 GB の redo ログファイルがいっぱいになっていない可能性があります。この場合、バックアップはトリガーされず、redo ログバックアップリストにレコードは表示されません。

はい、サポートされています。

いいえ、できません。ポイントインタイムリストアは、まず選択した時点より前の完全なデータバックアップをクラスターに復元します。その後、redo ログを使用して、選択した時点までデータを増分的に復元します。

はい、サポートされています。

はい、サポートされています。

いいえ、影響しません。PolarDB for MySQL は、復元操作では現在のクラスターに新しいデータベースとテーブルを作成します。