このページでは、ポイントインタイム リカバリを使用してプライマリ Cloud SQL インスタンスを復元する方法について説明します。
ポイントインタイム リカバリの詳細については、ポイントインタイム リカバリをご覧ください。
ポイントインタイム リカバリ用のログストレージ
ポイントインタイム リカバリでは、write-ahead log 書き込み(WAL)のアーカイブを使用します。デフォルトでは、Cloud SQL Enterprise Plus エディションのインスタンスではポイントインタイム リカバリが有効になっています。これらのインスタンスはすべて、指定したログ保持期間の間、Cloud Storage に WAL ログを保存します。2023 年 1 月 9 日、Google は、ポイントインタイム リカバリ用 WAL ログの Cloud Storage への保存を開始しました。Cloud SQL Enterprise エディションのインスタンスの場合、ポイントインタイム リカバリには次の条件が適用されます。
- このリリース後にポイントインタイム リカバリを有効にして作成された新しいインスタンスは、指定したログ保持期間の間、Cloud Storage にログを保存します。
- このリリース後にポイントインタイム リカバリを有効にした既存のインスタンスも、Cloud Storage にログが保存されます。
今回のリリース前にポイントインタイム リカバリを有効にしていた既存のインスタンスのログは、引き続きディスクに保存されます。
インスタンスのログが Cloud Storage に保存されているかどうかを確認するには、インスタンスの bytes_used_by_data_type 指標を確認します。archived_wal_log
データ型の値が 0
の場合、インスタンスのログは Cloud Storage に保存されます。
psql
や pgAdmin
などの PostgreSQL クライアントを使用してインスタンスのデータベースに接続したら、show archive_command
を実行します。WAL が Cloud Storage にアーカイブされている場合は、-async_archive -remote_storage
が表示されます。
ポイントインタイム リカバリが有効になっている他のすべての既存のインスタンスでは、引き続きログがディスクに保存されます。Cloud Storage にログを保存するようにする変更は、のちほど利用可能になります。
ログが Cloud Storage に保存されている場合、Cloud SQL は 5 分以内にログをアップロードします。その結果、Cloud SQL インスタンスが利用可能な場合、インスタンスを直近の時間に復元できます。ただし、インスタンスが利用できない場合、目標復旧時点は通常 5 分以内です。インスタンスを復元してその時点まで復元できる直近の時間を確認するために、API を使用します。
ポイントインタイム リカバリで使用される write-ahead log は、関連する自動バックアップによって自動的に削除されます。これは通常、transactionLogRetentionDays に設定された値に達すると行われます。これは、Cloud SQL がポイントインタイム リカバリのために保持するトランザクション ログの日数です。Cloud SQL Enterprise Plus エディションの場合、保持されるトランザクション ログの日数は 1~35 に設定できます。Cloud SQL Enterprise エディションの場合、値は 1~7 に設定できます。
ポイントインタイム リカバリを有効にする前に Cloud SQL インスタンスでバックアップを復元すると、ポイントインタイム リカバリの運用を可能にする WAL ログが失われます。
顧客管理の暗号鍵(CMEK)対応のインスタンスの場合、write-ahead log は最新バージョンの CMEK を使用して暗号化されます。復元を実施するには、retained-transaction-log-days
パラメータで構成した日数内で最も新しい鍵のすべてのバージョンが利用可能である必要があります。
write-ahead log が Cloud Storage に保存されているインスタンスの場合、ログはプライマリ インスタンスと同じリージョンに保存されます。このログストレージ(Cloud SQL Enterprise Plus エディションでは最大 35 日間、Cloud SQL Enterprise エディションでは最大 7 日間、ポイントインタイム リカバリの最大時間)では、インスタンスごとの追加コストは発生しません。
インスタンスでポイントインタイム リカバリが有効になっていて、ディスク上の write-ahead log のサイズが原因でインスタンスに問題が発生している場合は、以下のようにします。
ポイントインタイム リカバリを無効にして再度有効にすると、新しいログが Cloud Storage に保存されるようになります。ただし、既存の write-ahead log は削除されます。
インスタンスのストレージ サイズを増やすことはできますが、ディスク使用量の write-ahead log のサイズが大きくなるのはあくまで一時的です。
予期しないストレージの問題を避けるため、ストレージの自動増量を有効にすることをおすすめします。この推奨事項は、インスタンスでポイントインタイム リカバリが有効になっていて、ログがディスクに保存されている場合にのみ適用されます。
ログを削除してストレージを復元する場合は、ポイントインタイム リカバリを無効にします。ただし、使用する write-ahead log を減らしても、インスタンスにプロビジョニングされたディスクのサイズは縮小されません。
ログは継続的ではなく、1 日 1 回削除されます。ログの保持期間を 2 日に設定すると、少なくとも 2 日間、最大で 3 日間のログが保持されます。指定した日数分のログの保持を保証するために、バックアップの日数は、ログを保持する日数よりも 1 日長く設定することをおすすめします。
ポイントインタイム リカバリを有効にする
Google Cloud コンソールで新しいインスタンスを作成すると、[自動バックアップ] と [ポイントインタイム リカバリを有効にする] の両方が自動的に有効になります。次の手順では、既存のプライマリ インスタンスでポイントインタイム リカバリを有効にします。
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- ポイントインタイム リカバリを有効にするインスタンスの [その他の操作] メニュー を開き、[編集] をクリックします。
- [インスタンスのカスタマイズ] で、[データ保護] セクションを開きます。
- [ポイントインタイム リカバリを有効にする] チェックボックスをオンにします。
- [詳細オプション] を開きます。
- ログを保持する日数を Cloud SQL Enterprise Plus エディションの場合は 1~35、Cloud SQL Enterprise エディションの場合は 1~7 で指定します。
- [保存] をクリックします。
gcloud
- インスタンスの概要を表示します。
gcloud sql instances describe INSTANCE_NAME
backupConfiguration
セクションにenabled: false
が表示されている場合は、スケジュール バックアップを有効にします。gcloud sql instances patch INSTANCE_NAME \ --backup-start-time=HH:MM
backup-start-time
パラメータを UTC±00 タイムゾーンの 24 時間形式で指定します。- ポイントインタイム リカバリを有効にします。
gcloud sql instances patch INSTANCE_NAME \ --enable-point-in-time-recovery
プライマリ インスタンスでポイントインタイム リカバリを有効にする場合は、次のパラメータを追加して、トランザクション ログの保持日数を構成することもできます。
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- 変更を確定します。
gcloud sql instances describe INSTANCE_NAME
変更が成功すると、
backupConfiguration
セクションにpointInTimeRecoveryEnabled: true
が表示されます。
Terraform
ポイントインタイム リカバリを有効にするには、Terraform リソースを使用します。
変更を適用する
Google Cloud プロジェクトで Terraform 構成を適用するには、次のセクションの手順を完了します。
Cloud Shell を準備する
- Cloud Shell を起動します。
-
Terraform 構成を適用するデフォルトの Google Cloud プロジェクトを設定します。
このコマンドは、プロジェクトごとに 1 回だけ実行する必要があります。これは任意のディレクトリで実行できます。
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Terraform 構成ファイルに明示的な値を設定すると、環境変数がオーバーライドされます。
ディレクトリを準備する
Terraform 構成ファイルには独自のディレクトリ(ルート モジュールとも呼ばれます)が必要です。
-
Cloud Shell で、ディレクトリを作成し、そのディレクトリ内に新しいファイルを作成します。ファイルの拡張子は
.tf
にする必要があります(例:main.tf
)。このチュートリアルでは、このファイルをmain.tf
とします。mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
チュートリアルを使用している場合は、各セクションまたはステップのサンプルコードをコピーできます。
新しく作成した
main.tf
にサンプルコードをコピーします。必要に応じて、GitHub からコードをコピーします。Terraform スニペットがエンドツーエンドのソリューションの一部である場合は、この方法をおすすめします。
- 環境に適用するサンプル パラメータを確認し、変更します。
- 変更を保存します。
-
Terraform を初期化します。これは、ディレクトリごとに 1 回だけ行います。
terraform init
最新バージョンの Google プロバイダを使用する場合は、
-upgrade
オプションを使用します。terraform init -upgrade
変更を適用する
-
構成を確認して、Terraform が作成または更新するリソースが想定どおりであることを確認します。
terraform plan
必要に応じて構成を修正します。
-
次のコマンドを実行します。プロンプトで「
yes
」と入力して、Terraform 構成を適用します。terraform apply
Terraform に「Apply complete!」というメッセージが表示されるまで待ちます。
- Google Cloud プロジェクトを開いて結果を表示します。Google Cloud コンソールの UI でリソースに移動して、Terraform によって作成または更新されたことを確認します。
変更を削除する
変更を削除するには、次の手順を行います。
- 削除の保護を無効にするには、Terraform 構成ファイルで
deletion_protection
引数をfalse
に設定します。deletion_protection = "false"
- 次のコマンドを実行します。プロンプトで「
yes
」と入力して、更新された Terraform 構成を適用します。terraform apply
-
次のコマンドを実行しています。プロンプトで「
yes
」と入力して、以前に Terraform 構成で適用されたリソースを削除します。terraform destroy
REST v1
リクエストのデータを使用する前に、次のように置き換えます。
- project-id: プロジェクト ID
- instance-id: インスタンス ID
- start-time「HH:MM」形式の時刻
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
JSON 本文のリクエスト:
{ "settings": { "backupConfiguration": { "startTime": "start-time", "enabled": true, "pointInTimeRecoveryEnabled": true } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- project-id: プロジェクト ID
- instance-id: インスタンス ID
- start-time「HH:MM」形式の時刻
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
JSON 本文のリクエスト:
{ "settings": { "backupConfiguration": { "startTime": "start-time", "enabled": true, "pointInTimeRecoveryEnabled": true } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
最新の復旧時間を取得する
使用可能なインスタンスについては、ポイントインタイム リカバリを最新の時刻まで実行できます。インスタンスが使用不能になり、インスタンス ログが Cloud Storage に保存されている場合、最新の復旧時間を取得して、その時点までのポイントインタイム リカバリを実行できます。どちらの場合も、優先ゾーンの値を指定してインスタンスを別のゾーンに復元できます。
gcloud
使用不能な Cloud SQL インスタンスを復元できる最新の時刻を取得します。
INSTANCE_NAME は、クエリ対象のインスタンスの名前に置き換えます。
gcloud sql instances get-latest-recovery-time INSTANCE_NAME
REST v1
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- INSTANCE_NAME: 最新の復元時間をクエリするインスタンスの名前
HTTP メソッドと URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{ "kind": "sql#getLatestRecoveryTime", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID
- INSTANCE_NAME: 最新の復元時間をクエリするインスタンスの名前
HTTP メソッドと URL:
GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{ "kind": "sql#getLatestRecoveryTime", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
ポイントインタイム リカバリを実行する
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- 復元するインスタンスの [その他の操作] メニュー()を開き、[クローンを作成] をクリックします。
- 必要に応じて、[クローンの作成] ページで新しいクローンの ID を更新します。
- [過去の時点からクローンを作成] を選択します。
- ポイントインタイム リカバリ時間を入力します。
- [クローンを作成] をクリックします。
gcloud
ポイントインタイム リカバリを使用してクローンを作成します。
次のように置き換えます。
- SOURCE_INSTANCE_NAME - 復元元のインスタンスの名前。
- NEW_INSTANCE_NAME - クローンの名前。
- TIMESTAMP - ソース インスタンスの UTC タイムゾーン(RFC 3339 形式)。例: 2012-11-15T16:19:00.094Z
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --point-in-time 'TIMESTAMP'
REST v1
リクエストのデータを使用する前に、次のように置き換えます。
- project-id: プロジェクト ID
- target-instance-id: ターゲット インスタンス ID
- source-instance-id: ソース インスタンス ID
- restore-timestamp: 復元の終点となるポイントインタイム
HTTP メソッドと URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
JSON 本文のリクエスト:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- project-id: プロジェクト ID
- target-instance-id: ターゲット インスタンス ID
- source-instance-id: ソース インスタンス ID
- restore-timestamp: 復元の終点となるポイントインタイム
HTTP メソッドと URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
JSON 本文のリクエスト:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
ポイントインタイム リカバリを無効にする
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- 無効にするインスタンスの [その他の操作] メニュー を開き、[編集] を選択します。
- [インスタンスのカスタマイズ] で、[データ保護] セクションを開きます。
- [ポイントインタイム リカバリを有効にする] をクリアします。
- [保存] をクリックします。
- インスタンスの [概要] ページの [構成] で、ポイントインタイム リカバリの設定が無効と表示されます。
gcloud
- ポイントインタイム リカバリを無効にします。
gcloud sql instances patch INSTANCE_NAME \ --no-enable-point-in-time-recovery
- 変更を確定します。
gcloud sql instances describe INSTANCE_NAME
変更が成功すると、
backupConfiguration
セクションにpointInTimeRecoveryEnabled: false
が表示されます。
REST v1
リクエストのデータを使用する前に、次のように置き換えます。
- project-id: プロジェクト ID
- instance-id: インスタンス ID
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
JSON 本文のリクエスト:
{ "settings": { "backupConfiguration": { "enabled": false, "pointInTimeRecoveryEnabled": false } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- project-id: プロジェクト ID
- instance-id: インスタンス ID
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
JSON 本文のリクエスト:
{ "settings": { "backupConfiguration": { "enabled": false, "pointInTimeRecoveryEnabled": false } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
トランザクション ログの保持を設定する
write-ahead log を保持する日数を設定するには:
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- トランザクション ログを設定するインスタンスの [その他の操作] メニュー を開き、[編集] を選択します。
- [インスタンスのカスタマイズ] で、[データ保護] セクションを開きます。
- [ポイントインタイム リカバリを有効にする] セクションで、[詳細オプション] を開きます。
- ログを保持する日数を Cloud SQL Enterprise Plus エディションの場合は 1~35、Cloud SQL Enterprise エディションの場合は 1~7 で指定します。
- [保存] をクリックします。
gcloud
インスタンスを編集して、ログ先行書き込みログを保持する日数を設定します。
次のように置き換えます。
- INSTANCE-NAME - トランザクション ログを有効にするインスタンスの名前。
- DAYS-TO-RETAIN - トランザクション ログの保持日数。有効な範囲は、Cloud SQL Enterprise Plus エディションの場合は 1~35(デフォルト: 15)、Cloud SQL Enterprise Edition の場合は 1~7(デフォルト: 7)です。指定しない場合は、デフォルト値が使用されます。ポイントインタイム リカバリが有効になっている場合にのみ有効です。トランザクション ログをより長期間保持するには、より大きなストレージ サイズが必要になります。
gcloud sql instances patch INSTANCE-NAME
--retained-transaction-log-days=DAYS-TO-RETAIN
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- days-to-retain: トランザクション ログの保持日数(1~7)
- project-id: プロジェクト ID
- instance-id: インスタンス ID
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
JSON 本文のリクエスト:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "days-to-retain" } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
次のステップ
- クローンのフラグを構成する。