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 バックアップ、ログバックアップのデータ量とコストを削減する方法」をご参照ください。

  

いいえ。レベル 1 バックアップとデータバックアップの違いは次のとおりです。

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

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

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

• ESSD (エンタープライズ SSD) (PL0、PL1、PL2、PL3、および AutoPL)

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

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

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

• PSL4/PSL5

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

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

    • サブスクリプション (容量で課金)：ストレージ容量 × 50%。

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

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

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

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

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

    説明

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

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

    説明

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

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

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

    説明

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

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

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

はい。

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

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

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

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

次のいずれかの方法を使用して、PolarDB for MySQL バックアップファイルを Object Storage Service (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 操作を呼び出してバックアップジョブの BackupStatus フィールドを取得します。その後、そのステータスを確認し、ステータスが Failed の場合に、メール、ショートメッセージ、または監視プラットフォーム上の通知などのカスタムアラートをトリガーできます。

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

サポートされています。

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

サポートされています。

サポートされています。

いいえ、影響しません。PolarDB for MySQL は、リカバリオペレーションのために現在のクラスターに新しいデータベースとテーブルを作成します。