ポイント・イン・タイム・リカバリー
IBM Cloud® Databases for MySQL では、過去 7 日間の任意の時刻にポイント・イン・タイム・リカバリー (PITR) することができます。 このデプロイメントでは、増分バックアップが継続的に行われ、トランザクションを再生することで、バックアップから復元された新しいデプロイメントを、必要な7日間の期間内の任意の時点の状態に復元することができます。
デプロイメントのUIにある「 バックアップ 」タブには、「 ポイント・イン・タイム復旧 」の下に、すべてのPITR情報がまとめられています。
含まれている情報は、PITR できる最も古い時刻です。 CLI を使用して最も古いリカバリー・ポイントを検出するには、cdb mysql earliest-pitr-timestamp コマンドを使用します。
ibmcloud cdb mysql earliest-pitr-timestamp <deployment 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)」**をクリックすると、リカバリーのオプションが表示されます。 新規デプロイメントの名前を入力し、バージョン、リージョン、およびリソースの割り振り量を選択します。 **「リカバリー」**をクリックして、プロセスを開始します。
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 <SERVICE_INSTANCE_NAME> <service-id> <region> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP"}'
バックアップの詳細ビューでは、特定のバックアップまたは PITR のために事前に構成されたコマンドを利用できます。
CLI によるリストアの際に、オプションのパラメーターを使用できます。 新規デプロイメントのリソースをカスタマイズする必要がある場合や、新規デプロイメントで BYOK 暗号化の Key Protect 鍵を使用する場合は、それらのオプション・パラメーターを使用してください。
ibmcloud resource service-instance-create <SERVICE_INSTANCE_NAME> <service-id> 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"}'
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": "<SERVICE_INSTANCE_NAME>",
"target": "<region>",
"resource_group": "<your-resource-group>",
"resource_plan_id": "<service-id>",
"parameters":{
"point_in_time_recovery_time":"<TIMESTAMP>",
"point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
}
}'
パラメーターの name、target、resource_group、resource_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 はリストアするタイム・スタンプ
(UTC) です。 リストア可能な最新のポイント・イン・タイムにリストアする場合は、"point_in_time_recovery_time":" " を使用します。
リソースを調整したり Key Protect の鍵を使用したりする必要がある場合は、オプションのパラメーター key_protect_key、members_disk_allocation_mb、members_memory_allocation_mb、members_cpu_allocation_count と値を要求の本文に追加します。
PITR の検証
リカバリー時間が正しいことを確認するには、データベース・ログを確認してください。 データベースのログを参照するには、ロギングとの統合をデプロイメントにセットアップする必要があります。
リカバリーを実行すると、データは最新の増分バックアップからリストアされます。 WALログに残っている未処理のトランザクションは、復旧した時点までデータベースの状態を最新の状態に更新するために使用されます。 リカバリーが終了し、トランザクションが実行されると、ログにメッセージが表示されます。 ログに以下のメッセージが含まれているか確認してください。
LOG: last completed transaction was at log time 2019-09-03 19:40:48.997696+00
リカバリーがログに示されない状況が 2 つあります。
- デプロイメントに最新のフル・バックアップがあり、そのバックアップが取られた後に、再生する必要があるアクティビティーが発生していない。
- 入力したリカバリー時刻が、現在時刻より後か、リストア可能な最新のポイント・イン・タイム・リカバリーのポイントより後である場合。
どちらの場合も、リカバリーは通常成功しますが、データベースがリストアされた正確な時刻を確認できるエントリーがログに記録されません。