ポイント・イン・タイム・リカバリー

IBM Cloud® Databases for PostgreSQL では、過去 7 日間の任意の時刻にポイント・イン・タイム・リカバリー (PITR) することができます。 デプロイメントでは継続的に増分バックアップが実行されるので、トランザクションを再生することで、バックアップからリストアした新規デプロイメントを、7 日間の時間枠内の任意のポイントに戻すことができます。

配置の UI の[バックアップとリストア]タブには、すべての PITR 情報が[_ポイント イン タイム リカバリ]_の下に保持されます。

PostgreSQL バージョン 13 以降では、最後のトランザクションの後のリストア時間で、過去 7 日以内の特定のポイントにリストアすると、リストアが失敗し、メッセージ recovery ended before configured recovery target is reached が表示されます。 PostgreSQL v13より前では、最後のトランザクションの後のリストア時間で過去 7 日以内の特定のポイントにリストアする場合、最新のリストア・ポイントが使用されます。 この理由でリストアが失敗した場合は、 Restore to last available point を実行するか、 Restore to a specific point in the last 7 days に以前の日付/時刻を選択してください。

含まれている情報は、PITR できる最も古い時刻です。 CLI を使用して最も古いリカバリー・ポイントを検出するには、cdb postgresql earliest-pitr-timestamp コマンドを使用します。

ibmcloud cdb postgresql earliest-pitr-timestamp <INSTANCE_NAME_OR_CRN>

API を使用して最も古いリカバリー・ポイントを調べるには、/deployments/{id}/point_in_time_recovery_data エンドポイントを使用して、最も古い PITR 時刻を確認します。

{
    "point_in_time_recovery_data": {
        "earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
    }
}

回復

バックアップは新規デプロイメントにリストアされます。 新規デプロイメントがプロビジョニングを終了すると、バックアップ・ファイル内のデータが新規デプロイメントにリストアされます。 バックアップは、アカウント間でリストアすることもできますが、API を使用している場合で、かつ、リストアを実行するユーザーがソース・アカウントと宛先アカウントの両方へのアクセス権限を持っている場合に限られます。

デフォルトでは、新規デプロイメントは、リストア元のバックアップ時のソース・デプロイメントと同じディスクおよびメモリー割り振りに自動的にサイズ変更されます。 特に、デプロイメントの現在のサイズではない可能性がある PITR の場合には注意してください。 新規デプロイメントに割り振るリソース量を調整する必要がある場合は、UI、CLI、または API のフィールドを使用して新しいデプロイメントのサイズを変更します。 データとワークロードに十分な量を割り振ってください。デプロイメントに十分なリソースが指定されていない場合、リストアは失敗します。

ストレージとメモリーはソース・デプロイメントと同じにリストアされますが、新規インスタンスの固有のインスタンス構成は自動設定されません。 この場合は、リストア後の構成の再実行が必要になることがあります。 リストアの完了後にインスタンスを正確に設定するために、リストアを実行する前にインスタンスの変更 (shared_buffers、max_connections、deadlock_timeout、archive_timeout などのパラメーター) をメモします。

バックアップのリストア中にソース・デプロイメントを削除しないことが重要です。 古いデプロイメントを削除する前に、新規デプロイメントがプロビジョンされ、バックアップがリストアされるまで待機する必要があります。 配置を削除するとバックアップも削除されるため、リストアに失敗するだけでなく、バッ クアップを回復できなくなる可能性があります。

UI でのリカバリー

PITR を開始するには、復元先の時刻を協定世界時で入力します。 リストア可能な最新の時刻にリストアする場合は、そのオプションを選択します。 Restore ボタンをクリックすると、新しいプロビジョニングUIが表示され、リカバリーのためのオプションがタブに表示されます。 サービスの詳細を入力し、リソースを割り当て、新しいデプロイメント用にデータベースのバージョン、暗号化、エンドポイントを設定します。 ポイント・イン・タイム・リカバリーをクリックして処理を開始する。

Key Protectを使用し、キーを持っている場合は、CLIを使用して回復する必要があります。

CLI でのリカバリー

リソース・コントローラーはデータベース・デプロイメントのプロビジョニングをサポートしており、プロビジョニングとリストアはリソース・コントローラーの CLI で実行します。 resource service-instance-create コマンドを使用します。

PITR では、point_in_time_recovery_time パラメーターと point_in_time_recovery_deployment_id パラメーターを使用します。 point_in_time_recovery_deployment_idはソース・デプロイメントの ID であり、point_in_time_recovery_timeはリストア先の協定世界時のタイム・スタンプです。 使用可能な最新の特定時点にリストアするには、"point_in_time_recovery_time":" "を使用します。

ibmcloud resource service-instance-create <databases-for-postgresql> <INSTANCE_NAME> <REGION> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP", "version":" "}'

バックアップの詳細ビューでは、特定のバックアップまたは PITR のために事前に構成されたコマンドを利用できます。

CLI を使用してリストアする場合は、オプション・パラメーターを使用できます。 これらを使用してリソースをカスタマイズするか、新規デプロイメントで BYOK 暗号化用の Key Protect 鍵を使用します。

ibmcloud resource service-instance-create <databases-for-postgresql> <INSTANCE_NAME> standard <REGION> <--service-endpoints SERVICE_ENDPOINTS_TYPE> -p
'{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES", "version":" "}'

API でのリカバリー

リソース・コントローラーはデータベース・デプロイメントのプロビジョニングをサポートしており、プロビジョニングとリストアはリソース・コントローラー API で実行します。 リソース・コントローラー API を使用してバックアップからリストアする前に、リソース・コントローラー API を使用するために必要なステップを完了する必要があります。

すべての情報が表示されると、作成要求 POST/resource_instances エンドポイントに送信されます。

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<INSTANCE_NAME_OR_CRN>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE_GROUP>",
    "resource_plan_id": "<SERVICE_ID>"
    "point_in_time_recovery_time":"<TIMESTAMP>",
    "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
  }'

パラメーターの nametargetresource_groupresource_plan_id はすべて必須です。 target は、新規デプロイメントを配置するリージョンで、ソース・デプロイメントとは別のリージョンにすることもできます。 eu-deバックアップを別のリージョンにリストアする場合を除き、リージョン間リストアがサポートされます。

PITR では、point_in_time_recovery_time パラメーターと point_in_time_recovery_deployment_id パラメーターを使用します。 point_in_time_recovery_deployment_idはソース・デプロイメントの ID であり、point_in_time_recovery_timeはリストア先の協定世界時のタイム・スタンプです。 使用可能な最新の特定時点にリストアするには、"point_in_time_recovery_time":" "を使用します。

リソースを調整したり Key Protect の鍵を使用したりする必要がある場合は、オプションのパラメーター key_protect_keymembers_disk_allocation_mbmembers_memory_allocation_mbmembers_cpu_allocation_count と値を要求の本文に追加します。

PITR の検証

リカバリー時間が正しいことを確認するには、データベース・ログを確認してください。 データベースのログを参照するには、ロギングとの統合をデプロイメントにセットアップする必要があります。

リカバリーを実行すると、データは最新の増分バックアップからリストアされます。 WAL ログからの未解決のトランザクションは、リカバリーした時点までデータベースをリストアするために使用されます。 リカバリーが終了し、トランザクションが実行されると、ログにメッセージが表示されます。 ログにこのメッセージがあるかどうかは、以下のコマンドで確認できる:

LOG:  last completed transaction was at log time 2019-09-03 19:40:48.997696+00

リカバリーがログに示されない状況が 2 つあります。

  1. デプロイメントに最新のフル・バックアップがあり、そのバックアップが取られた後に、再生する必要があるアクティビティーが発生していない。
  2. 入力したリカバリー時刻が、現在時刻より後か、リストア可能な最新のポイント・イン・タイム・リカバリーのポイントより後である場合。

どちらの場合も、リカバリーは通常成功しますが、データベースがリストアされた正確な時刻を確認できるエントリーがログに記録されません。