このページでは、ポイントインタイム リカバリ(PITR)を使用してプライマリ Cloud SQL インスタンスを復元する方法について説明します。
PITR の詳細については、ポイントインタイム リカバリ(PITR)をご覧ください。
デフォルトでは、Google Cloud コンソール、gcloud CLI、Terraform、Cloud SQL Admin API のいずれを使用してインスタンスを作成した場合でも、Cloud SQL Enterprise Plus エディションのインスタンスを作成するときに PITR が有効になります。
Google Cloud コンソールで Cloud SQL Enterprise エディションのインスタンスを作成する場合、PITR はデフォルトで有効になります。それ以外の場合、gcloud CLI、Terraform、または Cloud SQL Admin API を使用してインスタンスを作成するときには、PITR を手動で有効にする必要があります。
PITR 用のログストレージ
Cloud SQL は、PITR に write-ahead log 書き込み(WAL)のアーカイブを使用します。2023 年 1 月 9 日、Google は、PITR 用 write-ahead log の Cloud Storage への保存を開始しました。このリリース以降、次の条件が適用されます。
- すべての Cloud SQL Enterprise Plus エディションのインスタンスは、write-ahead log を Cloud Storage に保存します。2023 年 1 月 9 日より前に Cloud SQL Enterprise エディションからアップグレードし、PITR を有効にした Cloud SQL Enterprise Plus エディションのインスタンスのみが、引き続きログをディスクに保存します。
- 2023 年 1 月 9 日より前に PITR を有効にして作成された Cloud SQL Enterprise エディションのインスタンスは、引き続きログをディスクに保存します。
- 2024 年 8 月 15 日以降に、ディスクに PITR のトランザクション ログを保存する Cloud SQL Enterprise エディションのインスタンスを Cloud SQL Enterprise Plus エディションにアップグレードすると、アップグレード プロセスで PITR に使用されるトランザクション ログの保存場所が Cloud Storage に切り替わります。詳細については、インプレース アップグレードを使用してインスタンスを Cloud SQL Enterprise Plus エディションにアップグレードするをご覧ください。
- 2023 年 1 月 9 日以降に PITR を有効にして作成したすべての Cloud SQL Enterprise エディションのインスタンスは、Cloud Storage にログを保存します。
write-ahead log をディスクにのみ保存するインスタンスの場合、gcloud CLI または Cloud SQL Admin API を使用して、PITR に使用されるトランザクション ログの保存場所をディスクから Cloud Storage に切り替えることができます。この操作でダウンタイムは発生しません。詳細については、トランザクション ログ ストレージを Cloud Storage に切り替えるをご覧ください。
ログの保持期間
インスタンスが PITR に使用されるログを Cloud Storage に保存しているかどうかを確認するには、PITR に使用されるトランザクション ログの保存場所を確認するを使用します。
psql
や pgAdmin
などの PostgreSQL クライアントを使用してインスタンスのデータベースに接続したら、show archive_command
を実行します。Write-ahead log が Cloud Storage にアーカイブされている場合は、-async_archive -remote_storage
が表示されます。
PITR が有効になっている他のすべての既存のインスタンスでは、引き続きログがディスクに保存されます。
ログが Cloud Storage に保存されている場合、Cloud SQL は 5 分以内ごとにログをアップロードします。その結果、Cloud SQL インスタンスが利用可能な場合、インスタンスを直近の時間に復元できます。ただし、インスタンスが利用できない場合、目標復旧時点は通常 5 分以内です。gcloud CLI または Admin API を使用して、インスタンスを復元し、その時点までの復元を実行できる直近の時間を確認します。
PITR で使用される write-ahead log は、関連する自動バックアップによって自動的に削除されます。この削除は通常、transactionLogRetentionDays
に設定された値に達すると行われます。これは、Cloud SQL が PITR のために保持するトランザクション ログの日数です。Cloud SQL Enterprise Plus エディションの場合、保持されるトランザクション ログの日数は 1~35 に設定できます。Cloud SQL Enterprise エディションの場合、値は 1~7 に設定できます。
PITR を有効にする前に Cloud SQL インスタンスでバックアップを復元すると、PITR の運用を可能にする write-ahead log が失われます。
顧客管理の暗号鍵(CMEK)対応のインスタンスの場合、write-ahead log は最新バージョンの CMEK を使用して暗号化されます。復元を実施するには、retained-transaction-log-days
パラメータで構成した日数内で最も新しい鍵のすべてのバージョンが利用可能である必要があります。
write-ahead log が Cloud Storage に保存されているインスタンスの場合、ログはプライマリ インスタンスと同じリージョンに保存されます。このログストレージ(Cloud SQL Enterprise Plus エディションでは最大 35 日間、Cloud SQL Enterprise エディションでは最大 7 日間、PRTR の最大時間)では、インスタンスごとの追加コストは発生しません。
ログとディスクの使用状況
インスタンスで PITR が有効になっていて、ディスク上の write-ahead log のサイズが原因でインスタンスに問題が発生している場合は、以下のようにします。
gcloud CLI または Cloud SQL Admin API を使用して、PITR に使用されるログの保存場所をディスクから Cloud Storage に切り替えることができます。この操作は、ダウンタイムなしで行うことができます。
インスタンスのストレージ サイズを増やすことはできますが、ディスク使用量のログ先行書き込みのサイズが大きくなるのはあくまで一時的です。
予期しないストレージの問題を避けるため、ストレージの自動増量を有効にすることをおすすめします。この推奨事項は、インスタンスで PITR が有効になっていて、ログがディスクに保存されている場合にのみ適用されます。
ログを削除してストレージを復元する場合は、PRTR を無効にします。ただし、使用する write-ahead log を減らしても、インスタンスにプロビジョニングされたディスクのサイズは縮小されません。
ログは継続的ではなく、1 日 1 回削除されます。ログの保持期間を 2 日に設定すると、少なくとも 2 日間、最大で 3 日間のログが保持されます。バックアップの日数は、ログの保持期間よりも 1 日長く設定することをおすすめします。
たとえば、
transactionLogRetentionDays
パラメータの値に7
を指定した場合、backupRetentionSettings
パラメータのretainedBackups
の値を8
に設定します。
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 リソースを使用します。
変更を適用する
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
-
以前に Terraform 構成で適用されたリソースを削除するには、次のコマンドを実行して、プロンプトに「
yes
」と入力します。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 を実行する
Console
次の理由により、使用できないインスタンスを別のゾーンに復元することがあります。
- インスタンスが構成されているゾーンにアクセスできない。このインスタンスは
FAILED
状態になっています。 - このインスタンスはメンテナンス中です。このインスタンスは
MAINTENANCE
状態になっています。
使用できないインスタンスを復元する手順は次のとおりです。
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- クローンを作成するインスタンスの行を見つけます。
- [アクション] 列で、 [その他の操作] メニューをクリックします。
- [クローンを作成] をクリックします。
- [クローンを作成] ページで、次の操作を行います。
- [インスタンス ID] フィールドで、必要に応じてインスタンス ID を更新します。
- 過去の時点からクローンを作成をクリック
- [ポイントインタイム] フィールドで、データのクローンを作成する日時を選択します。これにより、その時点のインスタンスの状態が復元されます。
- [クローンを作成] をクリックします。
クローンの初期化中に、インスタンスの一覧ページに戻ります。
gcloud
使用できないインスタンスを別のゾーンに復元する必要がある場合があります。これは、インスタンスが構成されているゾーンにアクセスできないためです。
gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \ --point-in-time DATE_AND_TIME_STAMP \ --preferred-zone ZONE_NAME \ --preferred-secondary-zone SECONDARY_ZONE_NAME
gcloud sql instances clone
コマンドを実行しているユーザーまたはサービス アカウントには、cloudsql.instances.clone
権限が必要です。gcloud CLI コマンドを実行するために必要な権限の詳細については、Cloud SQL の権限をご覧ください。
REST v1
使用できないインスタンスを別のゾーンに復元する必要がある場合があります。これは、インスタンスが構成されているゾーンにアクセスできないためです。
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- SOURCE_INSTANCE_NAME: ソース インスタンスの名前。
- TARGET_INSTANCE_NAME: ターゲット(クローン)インスタンスの名前。
- DATE_AND_TIME_STAMP: UTC タイムゾーンとRFC 3339形式(例:
2012-11-15T16:19:00.094Z
)のソース インスタンスの日付と時刻のスタンプ。 - ZONE_NAME: 省略可。ターゲット インスタンスのプライマリ ゾーンの名前。これは、クローンを作成する Cloud SQL インスタンスに別のプライマリ ゾーンを指定するために使用されます。リージョン インスタンスの場合、プライマリ ゾーンはこのゾーンに置き換わりますが、セカンダリ ゾーンはインスタンスと同じままです。
- SECONDARY_ZONE_NAME: 省略可。ターゲット インスタンスのセカンダリ ゾーンの名前。これは、クローンを作成するリージョン Cloud SQL インスタンスに別のセカンダリ ゾーンを指定するために使用されます。
HTTP メソッドと URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
リクエストの本文(JSON):
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_NAME", "pointInTime": "DATE_AND_TIME_STAMP", "preferredZone": "ZONE_NAME", "preferredSecondaryZone": "SECONDARY_ZONE_NAME" } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
instances.clone
API メソッドを使用するユーザーまたはサービス アカウントには、cloudsql.instances.clone
権限が必要です。API メソッドの使用に必要な権限の詳細については、Cloud SQL の権限をご覧ください。
REST v1beta4
使用できないインスタンスを別のゾーンに復元する必要がある場合があります。これは、インスタンスが構成されているゾーンにアクセスできないためです。
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- SOURCE_INSTANCE_NAME: ソース インスタンスの名前。
- TARGET_INSTANCE_NAME: ターゲット(クローン)インスタンスの名前。
- DATE_AND_TIME_STAMP: UTC タイムゾーンとRFC 3339形式(例:
2012-11-15T16:19:00.094Z
)のソース インスタンスの日付と時刻のスタンプ。 - ZONE_NAME: 省略可。ターゲット インスタンスのプライマリ ゾーンの名前。これは、クローンを作成する Cloud SQL インスタンスに別のプライマリ ゾーンを指定するために使用されます。リージョン インスタンスの場合、プライマリ ゾーンはこのゾーンに置き換わりますが、セカンダリ ゾーンはインスタンスと同じままです。
- SECONDARY_ZONE_NAME: 省略可。ターゲット インスタンスのセカンダリ ゾーンの名前。これは、クローンを作成するリージョン Cloud SQL インスタンスに別のセカンダリ ゾーンを指定するために使用されます。
HTTP メソッドと URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
リクエストの本文(JSON):
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_NAME", "pointInTime": "DATE_AND_TIME_STAMP", "preferredZone": "ZONE_NAME", "preferredSecondaryZone": "SECONDARY_ZONE_NAME" } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
instances.clone
API メソッドを使用するユーザーまたはサービス アカウントには、cloudsql.instances.clone
権限が必要です。API メソッドの使用に必要な権限の詳細については、Cloud SQL の権限をご覧ください。
最新の復旧時間を取得する
使用可能なインスタンスについては、最新の時刻まで 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 の時間を入力します。
- [クローンを作成] をクリックします。
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: 復元の終点となるポイントインタイム
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 レスポンスが返されます。
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 POSTGRES_12 us-central-1 DISK my_02 POSTGRES_12 us-central-1 CLOUD_STORAGE ...
コマンドの出力で、そのインスタンスでの PITR のトランザクション ログが保存されている場所に関する情報が、transactionalLogStorageState
フィールドまたは TRANSACTIONAL_LOG_STORAGE_STATE
列に示されます。トランザクション ログの保存状態には、次のようなものがあります。
DISK
: インスタンスは、PITR に使用されるトランザクション ログをディスクに保存します。 Cloud SQL Enterprise エディションのインスタンスを Cloud SQL Enterprise Plus エディションにアップグレードすると、アップグレード プロセスでログの保存場所が Cloud Storage に自動的に切り替わります。詳細については、インプレース アップグレードを使用してインスタンスを Cloud SQL Enterprise Plus エディションにアップグレードするをご覧ください。インスタンスのエディションをアップグレードせずに、ダウンタイムなしで gcloud CLI または Cloud SQL Admin API を使用してストレージ ロケーションを切り替えることもできます。詳細については、トランザクション ログ ストレージを Cloud Storage に切り替えるをご覧ください。SWITCHING_TO_CLOUD_STORAGE
: インスタンスが PITR トランザクション ログの保存場所を Cloud Storage に切り替えています。SWITCHED_TO_CLOUD_STORAGE
: インスタンスが、PITR トランザクション ログの保存場所をディスクから Cloud Storage に切り替えました。CLOUD_STORAGE
: インスタンスは、PITR に使用されるトランザクション ログを Cloud Storage に保存します。
トランザクション ログ ストレージを Cloud Storage に切り替える
インスタンスが PITR に使用されるトランザクション ログをディスクに保存している場合は、ダウンタイムが発生することなく保存場所を Cloud Storage に切り替えることができます。保存場所を切り替える全体的なプロセスは、トランザクション ログの保持期間(日数)とほぼ同じ時間で完了します。切り替えを開始するとすぐに、Cloud Storage にトランザクション ログが蓄積されます。オペレーション中は、PITR に使用されるトランザクション ログの保存場所を確認するのコマンドを使用して、プロセス全体のステータスを確認できます。
Cloud Storage への切り替えの全体的なプロセスが完了すると、Cloud SQL は PITR に Cloud Storage のトランザクション ログを使用します。
gcloud
ストレージ ロケーションを Cloud Storage に切り替えるには、次のコマンドを使用します。
gcloud sql instances patch INSTANCE_NAME \ --switch-transaction-logs-to-cloud-storage
INSTANCE_NAME は、インスタンス名で置き換えます。インスタンスは、レプリカ インスタンスではなくプライマリ インスタンスである必要があります。レスポンスは次の例のようになります。
The following message is used for the patch API method. {"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"} Patching Cloud SQL instance...done. Updated [https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
コマンドでエラーが返された場合は、Cloud Storage への切り替えのトラブルシューティングで次の手順を確認してください。
REST v1
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_ID: インスタンス ID。インスタンスはレプリカ インスタンスではなく、プライマリ インスタンスである必要があります。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{ "switchTransactionLogsToCloudStorageEnabled": true }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
リクエストでエラーが返された場合は、Cloud Storage への切り替えのトラブルシューティングで次の手順を確認してください。
REST v1beta4
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_ID: インスタンス ID。インスタンスはレプリカ インスタンスではなく、プライマリ インスタンスである必要があります。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
リクエストの本文(JSON):
{ "switchTransactionLogsToCloudStorageEnabled": true }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
リクエストでエラーが返された場合は、Cloud Storage への切り替えのトラブルシューティングで次の手順を確認してください。
トランザクション ログの保持を設定する
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 日で、デフォルトは 14 日です。Cloud SQL Enterprise エディションの場合、有効な範囲は 1 ~ 7 日で、デフォルトは 7 日です。
値が指定されていない場合は、デフォルト値が使用されます。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 レスポンスが返されます。
トラブルシューティング
問題 | トラブルシューティング |
---|---|
または
|
指定したタイムスタンプは無効です。 |
または
|
指定したタイムスタンプは、バックアップの時間または binlog 座標を発見できなかった時間です。 |
Cloud Storage への切り替えのトラブルシューティング
次の表に、トランザクション ログの保存場所をディスクから Cloud Storage に切り替えたときに INVALID REQUEST
コードとともに返される可能性のあるエラーを示します。
問題 | トラブルシューティング |
---|---|
Switching the storage location of the transaction logs
used for PITR is not supported for instances with database type %s.
|
Cloud SQL for MySQL インスタンスまたは Cloud SQL for PostgreSQL インスタンスで gcloud CLI コマンドを実行しているか、API リクエストを実行していることを確認します。Cloud SQL for SQL Server では、gcloud CLI または Cloud SQL Admin API を使用してトランザクション ログの保存場所を切り替えることはできません。 |
PostgreSQL transactional logging is not enabled on this instance.
|
PostgreSQL は、ポイントインタイム リカバリ(PITR)のトランザクション ログとしてログ先行書き込みを使用します。PITR をサポートするには、PostgreSQL でインスタンスのログ先行書き込みを有効にする必要があります。書き込み順序ロギングの有効化方法については、PITR を有効にするをご覧ください。 |
This instance is already storing transaction logs used for PITR in
Cloud Storage
|
トランザクション ログの保存場所を確認するには、PITR に使用されるトランザクション ログの保存場所を確認するのコマンドを実行します。 |
The instance is already switching transaction logs used for PITR from disk
to Cloud Storage.
|
スイッチ オペレーションが完了するまで待ちます。 オペレーションのステータスとトランザクション ログの保存場所を確認するには、PITR に使用されるトランザクション ログの保存場所を確認するのコマンドを実行します。 |
次のステップ
- クローンのフラグを構成する。