このページでは、ポイントインタイム リカバリ(PITR)を使用してプライマリ Cloud SQL インスタンスを復元する方法について説明します。
PITR の詳細については、ポイントインタイム リカバリ(PITR)をご覧ください。
Cloud SQL Enterprise Plus エディションのインスタンスを作成する場合、作成に使用した方法に関係なく、PITR はデフォルトで有効になります。この機能を無効にするには、手動で行う必要があります。
Cloud SQL Enterprise エディションのインスタンスを作成する場合、作成に使用した方法に関係なく、PITR はデフォルトで無効になります。この場合、この機能を有効にするには、手動で行う必要があります。
PITR 用のログストレージ
2024 年 5 月 31 日、Google は、PITR のトランザクション ログの Cloud Storage への保存を開始しました。今回のリリース以降、次の条件が適用されます。この日より前に作成された PITR 対応の Cloud SQL インスタンスでは、PITR トランザクション ログがディスクに保存されていました。これらのインスタンスのほとんどの PITR トランザクション ログは、その後 Cloud Storage に移行されています。特定のインスタンスのログのロケーションを確認するには、PITR に使用されるトランザクション ログの保存場所を確認するをご覧ください。
この日以降に PITR を有効にして作成されたすべての Cloud SQL インスタンスは、これらのログを Cloud Storage に保存します。
トランザクション ログは定期的に更新され、保存容量を使用します。Cloud SQL は、関連する自動バックアップとともにトランザクション ログを自動的に削除します。これは、transactionLogRetentionDays
パラメータに設定された値が満たされた後に行われます。このパラメータの詳細については、ログとディスクの使用状況をご覧ください。
トランザクション ログをディスクにのみ保存するインスタンスの場合、まず PITR を無効にしてから再度有効にすることで、Cloud Storage にログを保存するように Cloud SQL を構成できます。Cloud Storage からディスクにログを移動することはできません。
インスタンスのログがディスクではなく Cloud Storage に保存されるようにするには、次の操作を行います。
- インスタンスがログをディスクまたは Cloud Storage のどちらに保存するのかを確認します。
- インスタンスのネットワーク アーキテクチャを確認します。 インスタンスが古いネットワーク アーキテクチャを使用している場合は、新しいネットワーク アーキテクチャにアップグレードします。
- ディスク上のログのサイズが原因でインスタンスのパフォーマンスの問題が発生している場合は、PITR を無効にしてから再度有効にします。
ログとディスクの使用状況
Cloud Storage に保存されているトランザクション ログのあるインスタンスの場合、ログはプライマリ インスタンスと同じリージョンに保存されます。このログストレージ(Cloud SQL Enterprise Plus エディションでは最大 35 日間、Cloud SQL Enterprise エディションでは最大 7 日間、PRTR の最大時間)では、インスタンスごとの追加コストは発生しません。
Cloud SQL がログを定期的に生成し、これらのログは保存容量を使用します。Cloud SQL は、関連する自動バックアップとともにトランザクション ログを自動的に削除します。これは、transactionLogRetentionDays
パラメータに設定した値が満たされた後に行われます。このパラメータは、Cloud SQL がトランザクション ログを保持する日数を指定します。Cloud SQL Enterprise Plus エディションの場合、トランザクション ログを保持する日数は 1~35 に設定できます。Cloud SQL Enterprise エディションの場合、この値は 1~7 に設定できます。
このパラメータの値が設定されていない場合、デフォルトのトランザクション ログ保持期間は、Cloud SQL Enterprise Plus エディションのインスタンスでは 14 日間、Cloud SQL Enterprise エディションのインスタンスでは 7 日間に設定されます。この設定を適用する方法については、トランザクション ログの保持期間を設定するをご覧ください。
トランザクション ログで使用されているディスク容量を確認するには、インスタンスの bytes_used_by_data_type
指標を確認します。データ型の値は、ディスク上のトランザクション ログのサイズを示します。PITR に使用されるトランザクション ログをディスクに保存するインスタンスの場合、Cloud SQL は transactionLogRetentionDays
PITR 設定を満たすために、毎日ディスクからデータを削除します。詳細については、自動バックアップの保持期間をご覧ください。
制限事項
インスタンスで PITR が有効になっていて、ディスク上のトランザクション ログのサイズが原因でインスタンスに問題が発生している場合、次の制限が適用されます。
- PITR を無効にして再度有効にすると、Cloud SQL がログをインスタンスと同じリージョンの Cloud Storage に保存するようになります。ただし、Cloud SQL は既存のログを削除するため、PITR を再度有効にした時点よりも前に PITR オペレーションを実行することはできません。
- インスタンスのストレージ サイズを増やすことはできますが、ディスク使用量のトランザクションログ サイズの増加は一時的なものである可能性があります。
- 予期しないストレージの問題を回避するには、ストレージの自動増量を有効にすることをおすすめします。この推奨事項は、インスタンスで PITR が有効になっていて、ログがディスクに保存されている場合にのみ適用されます。
- ログを削除してストレージを復元する場合、PITR を無効にして、再度有効にしないことができます。ただし、使用されるストレージを減らしても、インスタンスにプロビジョニングされたディスクのサイズは縮小しません。
ログは継続的ではなく、1 日 1 回削除されます。ログの保持期間を 2 日に設定すると、少なくとも 2 日間、最大で 3 日間のログが保持されます。バックアップの日数は、ログの保持期間よりも 1 日長く設定することをおすすめします。
たとえば、
transactionLogRetentionDays
パラメータの値に7
を指定した場合、backupRetentionSettings
パラメータのretainedBackups
の値を8
に設定します。
PITR の詳細については、ポイントインタイム リカバリ(PITR)をご覧ください。
PITR 用のデータベース復旧モデル
インスタンスで PITR を有効にすると、Cloud SQL は既存のデータベースと後続のデータベースの復旧モデルを自動的に完全復旧モデルに設定します。
SQL Server の復旧モデルの詳細については、Microsoft のドキュメントをご覧ください。
PITR を有効にする
Google Cloud コンソールで新しいインスタンスを作成すると、[自動バックアップ] の設定が自動的に有効になります。次の手順では、既存のプライマリ インスタンスで PITR を有効にします。
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- PITR を有効にするインスタンスの [その他の操作] メニュー
を開き、[編集] をクリックします。
- [インスタンスのカスタマイズ] で、[データ保護] セクションを開きます。
- [ポイントインタイム リカバリを有効にする] チェックボックスをオンにします。
- [ログの日数] フィールドに、ログを保持する日数を入力します。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 時間形式で指定します。- PITR を有効にします。
gcloud sql instances patch INSTANCE_NAME \ --enable-point-in-time-recovery
プライマリ インスタンスで PITR を有効にする場合は、次のパラメータを追加して、トランザクション ログの保持日数を構成することもできます。
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- 変更を確定します。
gcloud sql instances describe INSTANCE_NAME
変更が成功すると、
backupConfiguration
セクションにpointInTimeRecoveryEnabled: true
が表示されます。
Terraform
PITR を有効にするには、Terraform リソースを使用します。
Cloud SQL Enterprise Plus エディションで PITR を有効にする
次の Terraform コードサンプルを使用して、PITR を有効にした Cloud SQL Enterprise Plus エディション インスタンスを作成します。Cloud SQL Enterprise エディションで PITR を有効にする
次の Terraform コードサンプルを使用して、PITR を有効にした Cloud SQL Enterprise エディション インスタンスを作成します。変更を適用する
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: インスタンスが含まれている Google Cloud プロジェクトの ID またはプロジェクト番号
- INSTANCE_NAME: 高可用性構成を行うプライマリまたはリードレプリカ インスタンスの名前
- START_TIME: 時刻(時と分)
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
リクエストの本文(JSON):
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "pointInTimeRecoveryEnabled": true } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: インスタンスが含まれている Google Cloud プロジェクトの ID またはプロジェクト番号
- INSTANCE_NAME: 高可用性構成を行うプライマリまたはリードレプリカ インスタンスの名前
- START_TIME: 時刻(時と分)
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
リクエストの本文(JSON):
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "pointInTimeRecoveryEnabled": true } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
最新の復旧時間を取得する
使用可能なインスタンスについては、最新の時刻まで PITR を実行できます。インスタンスが使用不能になり、インスタンス ログが Cloud Storage に保存されている場合、最新の復元時刻を取得して、その時点までの PITR を実行できます。どちらの場合も、優先ゾーンの値を指定してインスタンスを別のプライマリ ゾーンまたはセカンダリ ゾーンに復元できます。
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" }
PITR を実行する
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- 復元するインスタンスの [その他の操作] メニュー
を開き、[クローンを作成] をクリックします。
- 必要に応じて、[クローンの作成] ページで新しいクローンの ID を更新します。
- [過去の時点からクローンを作成] を選択します。
- PITR の時刻を入力します。
- [すべてのデータベース] を選択するか、データベース名を指定します。
データベース名を指定すると、1 つのみ選択されます。デフォルトでは、PITR はすべてのデータベースに適用されます。 - [クローンを作成] をクリックします。
gcloud
PITR を使用してクローンを作成します。
次のように置き換えます。
- 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: 復元の終点となるポイントインタイム
JSON リクエストでは、必要に応じて最大 1 つのデータベース名を指定できます。次に例を示します。"databaseNames": "my-database"
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: 復元の終点となるポイントインタイム
JSON リクエストでは、必要に応じて最大 1 つのデータベース名を指定できます。次に例を示します。"databaseNames": "my-database"
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 レスポンスが返されます。
PITR を無効にする
コンソール
-
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 レスポンスが返されます。
PITR に使用されるトランザクション ログの保存場所を確認する
PITR に使用されるトランザクション ログが、Cloud SQL インスタンスによってどこに保存されるのかを確認できます。
gcloud
インスタンスが PITR のログをディスクまたは Cloud Storage のどちらに保存するかを確認するには、次のコマンドを使用します。
gcloud sql instances describe INSTANCE_NAME
INSTANCE_NAME は、インスタンス名で置き換えます。
同じプロジェクト内の複数のインスタンスのトランザクション ログの保存場所を確認することもできます。複数のインスタンスのロケーションを確認するには、次のコマンドを使用します。
gcloud sql instances list --show-transactional-log-storage-state
レスポンスの例:
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE my_01 SQLSERVER_2019_STANDARD us-central-1 DISK my_02 SQLSERVER_2019_STANDARD us-central-1 CLOUD_STORAGE ...
コマンドの出力で、そのインスタンスでの PITR のトランザクション ログが保存されている場所に関する情報が、transactionalLogStorageState
フィールドまたは TRANSACTIONAL_LOG_STORAGE_STATE
列に示されます。トランザクション ログの保存状態には、次のようなものがあります。
DISK
: インスタンスは、PITR に使用されるトランザクション ログをディスクに保存します。CLOUD_STORAGE
: インスタンスは、PITR に使用されるトランザクション ログを Cloud Storage に保存します。
トランザクション ログの保持を設定する
トランザクション ログの保持日数を設定するには:
コンソール
-
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 日で、デフォルトは 14 日です。Cloud SQL Enterprise エディションの場合、有効な範囲は 1~7 日で、デフォルトは 7 日です。
値を指定しない場合、Cloud SQL はデフォルト値を使用します。この設定は、PITR が有効な場合にのみ効果があります。トランザクション ログをより長期間保持するには、より大きなストレージ サイズが必要になります。
gcloud sql instances patch INSTANCE_NAME
--retained-transaction-log-days=DAYS_TO_RETAIN
REST v1
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_ID: インスタンス ID。
DAYS_TO_RETAIN: トランザクション ログを保持する日数。Cloud SQL Enterprise Plus エディションの場合、有効な範囲は 1~35 日で、デフォルトは 14 日です。Cloud SQL Enterprise エディションの場合、有効な範囲は 1~7 日で、デフォルトは 7 日です。
値が指定されていない場合は、デフォルト値が使用されます。この設定は、PITR が有効な場合にのみ効果があります。トランザクション ログをより長期間保持するには、より大きなストレージ サイズが必要になります。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_ID: インスタンス ID。
DAYS_TO_RETAIN: トランザクション ログを保持する日数。Cloud SQL Enterprise Plus エディションの場合、有効な範囲は 1~35 日で、デフォルトは 14 日です。Cloud SQL Enterprise エディションの場合、有効な範囲は 1~7 日で、デフォルトは 7 日です。
値が指定されていない場合は、デフォルト値が使用されます。この設定は、PITR が有効な場合にのみ効果があります。トランザクション ログをより長期間保持するには、より大きなストレージ サイズが必要になります。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
トラブルシューティング
問題 | トラブルシューティング |
---|---|
または
|
指定したタイムスタンプは無効です。 |
または
|
指定したタイムスタンプは、バックアップの時間またはバイナリログ座標を発見できなかった時間です。 |
次のステップ
- クローンのフラグを構成する。