ポイントインタイムリカバリ（PITR）を使用する

MySQL | PostgreSQL | SQL Server

このページでは、ポイントインタイムリカバリ（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 にバイナリログを使用します。

2023 年 8 月 11 日、Google は、PITR のトランザクションログの Cloud Storage への保存を開始しました。今回のリリース以降、次の条件が適用されます。

Cloud SQL Enterprise Plus エディションのインスタンスはすべて、PITR に使用されるバイナリログを Cloud Storage に保存します。2024 年 4 月 1 日より前に Cloud SQL Enterprise エディションからアップグレードし、2023 年 8 月 11 日より前に PITR を有効にした Cloud SQL Enterprise Plus エディションのインスタンスのみが、PITR のログをディスクに保存します。
2023 年 8 月 11 日より前に PITR を有効にして作成された Cloud SQL Enterprise エディションのインスタンスは、引き続き PITR のログをディスクに保存します。

注: 2023 年 8 月 11 日より前に作成されたインスタンスの場合、Cloud SQL で PITR 用のトランザクションログの場所が自動的に切り替わります。gcloud CLI または Cloud SQL Admin API を使用して、インスタンスのトランザクションログが保存されている場所を確認できます。
2024 年 4 月 1 日以降に、PITR 用のトランザクションログをディスクに保存する Cloud SQL Enterprise エディションのインスタンスを Cloud SQL Enterprise Plus エディションにアップグレードすると、アップグレードプロセスで PITR 用のトランザクションログの保存場所が Cloud Storage に切り替わります。詳細については、インプレースアップグレードを使用してインスタンスを Cloud SQL Enterprise Plus エディションにアップグレードするをご覧ください。
2023 年 8 月 11 日以降に PITR を有効にして作成したすべての Cloud SQL Enterprise エディションのインスタンスは、PITR に使用されるログを Cloud Storage に保存します。

PITR に使用されるトランザクションログの保存場所を確認する方法については、PITR に使用されるトランザクションログの保存場所を確認するをご覧ください。

ディスクにのみバイナリログを保存するインスタンスの場合、gcloud CLI または Cloud SQL Admin API を使用して、PITR 用のトランザクションログの保存場所をディスクから Cloud Storage にダウンタイムなしで切り替えることができます。詳細については、トランザクションログストレージを Cloud Storage に切り替えるをご覧ください。

ログの保持期間

Cloud SQL は、transactionLogRetentionDays PITR 構成設定で設定された値まで、Cloud Storage にトランザクションログを保持します。この値は、Cloud SQL Enterprise Plus エディションでは 1～35 日、Cloud SQL Enterprise エディションでは 1～7 日の範囲に設定できます。このパラメータの値が設定されていない場合、デフォルトのトランザクションログ保持期間は、Cloud SQL Enterprise Plus エディションのインスタンスでは 14 日間、Cloud SQL Enterprise エディションのインスタンスでは 7 日間です。トランザクションログの保持期間を設定する方法については、トランザクションログの保持期間を設定するをご覧ください。

インスタンスは、PITR に使用されるバイナリログを Cloud Storage に保存しますが、ログを Cloud Storage にレプリケートできるように、少数の重複バイナリログをディスクにも保持します。デフォルトでは、PITR を有効にしてインスタンスを作成すると、インスタンスは PITR のバイナリログを Cloud Storage に保存します。Cloud SQL では、expire_logs_days フラグと binlog_expire_logs_seconds フラグの値も 1 日に相当する値に自動的に設定されます。これらの設定値で、ディスクに 1 日分のログが保存されます。

PITR バイナリログがディスクに保存されている場合、Cloud Storage に切り替えられている場合、またはすでに Cloud Storage に切り替えられた場合、Cloud SQL は次の構成に設定された値のうち最短となる期間、ログを保持します。

transactionLogRetentionDays バックアップ構成設定
expire_logs_days フラグまたは binlog_expire_logs_seconds フラグ

バイナリログがディスクに保存されている場合、Cloud Storage に切り替えられている場合、またはすでに Cloud Storage に切り替えられた場合、Cloud SQL はこれらのフラグの値を設定しません。ログがディスクに保存されている場合、これらのフラグの値を変更すると、PITR の復元の動作や、何日分のログがディスクに保存されるかに影響する可能性があります。ログの保存場所が Cloud Storage に切り替えられている間は、これらの値を変更することはできません。また、いずれかのフラグの値を 0 に構成することはおすすめしません。これらのフラグについて詳しくは、データベースフラグを構成するをご覧ください。

顧客管理の暗号鍵（CMEK）対応のインスタンスの場合、バイナリログは最新バージョンの CMEK を使用して暗号化されます。復元を実施するには、retained-transaction-log-days パラメータで構成した日数におけるすべての最新バージョンの鍵が利用できる必要があります。

ログとディスクの使用状況

ログは定期的に生成されてストレージを使用します。バイナリログは、関連する自動バックアップによって自動的に削除されます。この削除は、transactionLogRetentionDays に設定されている値に達したときに行われます。

バイナリログによって使用されているディスク容量を確認するには、インスタンスの bytes_used_by_data_type 指標を確認します。binlog データ型の値は、ディスクのバイナリログのサイズを返します。PITR に使用されるトランザクションログをディスクに保存するインスタンスの場合、自動バックアップとトランザクションログの保持で説明されているように、Cloud SQL は transactionLogRetentionDays PITR 設定を満たすために、毎日ディスクからデータを削除します。ただし、expire_logs_days フラグまたは binlog_expire_logs_seconds フラグをトランザクションログの保持期間よりも短い値に設定すると、Cloud SQL はバイナリログをより早く削除できます。

バイナリログのサイズが原因でインスタンスに問題が発生している場合:

インスタンスがログをディスクに保存しているかどうかを確認します。gcloud CLI または Cloud SQL Admin API を使用して、ダウンタイムなしで、ディスクから Cloud Storage に PITR 用のログの保存場所を切り替えることができます。Cloud SQL Enterprise エディションを使用している場合は、Cloud SQL Enterprise Plus エディションにアップグレードすることで、PITR ログの保存場所を切り替えることもできます。
インスタンスのストレージサイズを増やすことはできますが、ディスク使用量のバイナリログサイズの増加は一時的である可能性があります。
予期しないストレージの問題を避けるため、ストレージの自動増量を有効にすることをおすすめします。
ログを削除してディスクの保存容量を回復する場合は、PITR を無効にすることができ、再度有効にする必要はありません。ただし、使用されるストレージを減らしても、インスタンスにプロビジョニングされたディスクのサイズは縮小しません。
ログは継続的にではなく、1 日 1 回削除されます。ログの保持期間を 2 日に設定すると、少なくとも 2 日間、最大で 3 日間のログが保持されます。バックアップの日数は、ログの保持期間よりも 1 日長く設定することをおすすめします。

たとえば、transactionLogRetentionDays パラメータの値に 7 を指定した場合、backupRetentionSettings パラメータの retainedBackups の値を 8 に設定します。

PITR の詳細については、ポイントインタイムリカバリ（PITR）をご覧ください。

トランザクションログの保存場所を Cloud Storage に切り替えるプロセスが完了した後、expire_logs_days フラグまたは binlog_expire_logs_seconds フラグの値を減らしてディスク容量を解放できます。切り替えのステータスを確認するには、PITR に使用されるトランザクションログの保存場所を確認するをご覧ください。ディスクで追加のログを使用できるようにする場合（たとえば、mysqlbinlog ユーティリティでバイナリログをブラウジングする場合）は、これらのフラグの値を増やします。Cloud SQL は、トランザクションログの保持期間とフラグに設定された値のうち最短となる期間、ディスクにバイナリログを保持します。切り替え後に PITR 用のログがどのように保存されるかについては、またディスク容量を解放する方法については、Cloud Storage への切り替え後のログをご覧ください。

PITR を有効にする

Google Cloud コンソールで新しいインスタンスを作成すると、[自動バックアップ] と [ポイントインタイムリカバリを有効にする] の両方が自動的に有効になります。

次の手順では、既存のプライマリインスタンスで PITR を有効にします。

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

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-bin-log
```
プライマリインスタンスで PITR を有効にする場合は、次のパラメータを追加して、トランザクションログの保持日数を構成することもできます。
```
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
```
変更を確定します。
```
gcloud sql instances describe INSTANCE_NAME
```
変更が成功すると、backupConfiguration セクションに binaryLogEnabled: true が表示されます。

Terraform

PITR を有効にするには、Terraform リソースを使用します。

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance-pitr"
  region           = "asia-northeast1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-f1-micro"
    backup_configuration {
      enabled                        = true
      binary_log_enabled             = true
      start_time                     = "20:55"
      transaction_log_retention_days = "3"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

変更を適用する

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,
      "binaryLogEnabled": true
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ユーザーアカウントで gcloud CLI にログインしているか、Cloud Shell を使用して自動的に gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell（Windows）

注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ご自分のユーザーアカウントで gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

リクエストのデータを使用する前に、次のように置き換えます。

PROJECT_ID: インスタンスが含まれている Google Cloud プロジェクトの ID またはプロジェクト番号
INSTANCE_NAME: 高可用性構成を行うプライマリまたはリードレプリカインスタンスの名前
START_TIME: 時刻（時と分）

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

リクエストの本文（JSON）:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

タイムスタンプを使用して PITR を実行する

PITR を実行する場合は、タイムスタンプを使用することをおすすめします。Cloud SQL は、mysqlbinlog ユーティリティを使用して、特定の時間までインスタンスを復元します。mysqlbinlog ユーティリティの詳細については、MySQL リファレンスドキュメントをご覧ください。

以下のタスクを完了するには、次のことが必要です。

インスタンスでバイナリロギングとバックアップが有効になっていて、復元するイベントの前の最後のバックアップ以降、インスタンスでバイナリログが継続されている。詳細については、バイナリロギングを有効にするをご覧ください。
復元ポイントを定義するタイムスタンプ。このタイムスタンプ以降に発生したイベントは、新しいインスタンスに反映されません。

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

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"
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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"
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

PITR を無効にする

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

Cloud SQL の [インスタンス] に移動
無効にするインスタンスの [その他の操作] メニューを開き、[編集] を選択します。
[インスタンスのカスタマイズ] で、[データ保護] セクションを開きます。
[ポイントインタイムリカバリを有効にする] をクリアします。
[保存] をクリックします。

gcloud

ポイントインタイムリカバリを無効にします。

gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log

変更を確定します。
```
gcloud sql instances describe INSTANCE_NAME
```
変更が成功すると、backupConfiguration セクションに binaryLogEnabled: 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,
      "binaryLogEnabled": false
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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,
      "binaryLogEnabled": false
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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 MYSQL_8_0        us-central-1     DISK
my_02 MYSQL_8_0        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 で Cloud Storage のトランザクションログが PITR に使用されます。

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
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

リクエストでエラーが返された場合は、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
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

リクエストでエラーが返された場合は、Cloud Storage への切り替えのトラブルシューティングで、考えられる対応策を確認してください。

切り替え後のトランザクションログの保存と構成

インスタンスの Cloud Storage への切り替えプロセスが完了しても、Cloud SQL はレプリケーション目的でバイナリログのコピーをディスクに引き続き保持します。mysqlbinlog ユーティリティでバイナリログをブラウジングする場合は、ディスクにバイナリログを保存すると便利です。

切り替え前にインスタンスで expire_logs_days フラグまたは binlog_expire_logs_seconds フラグを構成した場合、構成済みの値はそのまま残ります。

切り替え後、PITR の実行に使用されるバイナリログは Cloud Storage に保存されるため、フラグの値が、想定どおりにディスク上のトランザクションログの保持を反映するようにします。Cloud SQL は、次の値のうち最短となる期間だけ、ログをディスクに保持します。

切り替え前の transactionLogRetentionDays PITR 構成設定。この設定のデフォルト値は 7 日です。
インスタンスに手動で設定した expire_logs_days フラグまたは binlog_expire_logs_seconds フラグ。

ディスク容量を節約する場合は、切り替えプロセスが完了した後、expire_logs_days フラグまたは binlog_expire_logs_seconds フラグの値を 1 日に構成すれば、割り当てられるディスクサイズとディスクストレージの費用を削減できます。トランザクションログストレージと PITR の詳細については、PITR 用のログストレージをご覧ください。

ディスクの使用状況を確認する方法については、ログとディスクの使用状況をご覧ください。

トランザクションログの保持を設定する

バイナリログの保持日数を設定するには:

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

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"
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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"
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

バイナリログの位置を使用して PITR を実行する

タイムスタンプを使用して PITR を実行するで説明したように、タイムスタンプを使用して PITR を実行することをおすすめしますが、バイナリログファイルで特定のバイナリログの位置を指定することで、PITR を実行することもできます。

バイナリログの位置を使用した PITR の詳細については、MySQL リファレンスのバイナリログを使用した PITR をご覧ください。

始める前に

このタスクを行う前に、次のことを確認する必要があります。

インスタンスでバイナリロギングとバックアップが有効になっていて、復元するイベントの前の最後のバックアップ以降、インスタンスでバイナリロギングが継続されている。詳細については、バイナリロギングを有効にするをご覧ください。
バイナリログをディスクで使用できるようにすると、イベントを参照できます。ディスクのバイナリログの保持期間を確認するには、ログの保持期間をご覧ください。mysqlbinlog ユーティリティを使用して、Cloud Storage に保存されているバイナリログを参照することはできません。
バイナリログファイル名と復元に使用するイベントの位置（このイベントとその後のすべてのイベントは新しいインスタンスに反映されません）。詳細については、バイナリログの位置を特定するをご覧ください。

バイナリログファイル名と位置を特定したら、バイナリログイベントの位置を使用して PITR を実行します。

復元位置を特定する

MySQL クライアントを使用して、復元するインスタンスに接続します。

そのためには、Cloud Shell またはローカルクライアントマシンを使用します。詳細については、外部アプリケーションの接続オプションをご覧ください。
インスタンスのバイナリログファイルを表示します。
```
SHOW BINARY LOGS;
```
最新のバイナリログファイルの最初のイベント 100 件を表示します。
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
```
表示する行数は調整できますが、ファイルのサイズが大きい場合、ファイル内のすべてのイベントが表示されるとは限りません。表示するイベント数が多いと、システムのパフォーマンスに影響します。
探しているイベントがない場合は、開始位置として表示されている最後の位置を使用して、次のイベントセットを検索します。
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
```
復元する時点をマークするイベントが見つかったら、位置（Pos に表示）とバイナリログファイルの名前を記録します。

バイナリログファイル名と位置の値は、PITR で使用します。

以下に SHOW BINLOG EVENTS コマンドの出力例を示します。

+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| mysql-bin.000011 |   4 | Format_desc |  88955285 |         120 | Server ver: 5.6.30-log, Binlog ver: 4               |
| mysql-bin.000011 | 120 | Query       |  88955285 |         211 | create database db1                                 |
| mysql-bin.000011 | 211 | Query       |  88955285 |         310 | use `db1`; CREATE TABLE t (c CHAR(20))              |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |
| mysql-bin.000011 | 381 | Table_map   |  88955285 |         426 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |

| mysql-bin.000011 | 426 | Write_rows  |  88955285 |         464 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 464 | Xid         |  88955285 |         495 | COMMIT /* xid=56 */                                 |
| mysql-bin.000011 | 495 | Query       |  88955285 |         566 | BEGIN                                               |
| mysql-bin.000011 | 566 | Table_map   |  88955285 |         611 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 611 | Write_rows  |  88955285 |         649 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 649 | Xid         |  88955285 |         680 | COMMIT /* xid=57 */                                 |
| mysql-bin.000011 | 680 | Query       |  88955285 |         751 | BEGIN                                               |
| mysql-bin.000011 | 751 | Table_map   |  88955285 |         796 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 796 | Write_rows  |  88955285 |         834 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 834 | Xid         |  88955285 |         865 | COMMIT /* xid=58 */                                 |
| mysql-bin.000011 | 865 | Query       |  88955285 |         977 | use `db1`; DROP TABLE `t` /* generated by server */ |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
16 rows in set (0.04 sec)

上記の太字の DROP TABLE ステートメントまで復元するには、リカバリ位置として「mysql-bin.000011」の「865」を使用します。DROP TABLE ステートメントとそれ以降のすべてのオペレーションは、新しいインスタンスには反映されません。

バイナリログイベントの位置を使用して PITR を実行する

gcloud

--bin-log-file-name フラグと --bin-log-position フラグを指定して、gcloud sql instances clone コマンドを使用します。

バイナリログのファイル名と復元位置を使用して新しいインスタンスを作成します。

次のように置き換えます。
- SOURCE_INSTANCE_NAME: 復元元のインスタンスの名前。
- NEW_INSTANCE_NAME: クローンの名前。
- BINLOG_FILE_NAME: バイナリログの名前（mysql-bin.187288 など）。
- POSITION: 復元するバイナリログ内の位置（50001356 など）。
```
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--bin-log-file-name="BINLOG_FILE_NAME" \
--bin-log-position=POSITION
```
たとえば、gcloud sql instances clone コマンドは次のようになります。
```
gcloud sql instances clone instance1 \
instance1-clone \
--bin-log-file-name=mysql-bin.0000031 \
--bin-log-position=107 \
```
復元オペレーションのステータスを確認するには、clone コマンドから返されたオペレーション ID を使用します。
```
gcloud sql operations describe OPERATION_ID
```
オペレーションが進行中の場合は、状態として RUNNING が返されます。オペレーションが完了すると、状態として DONE が返されます。

REST v1

確認したバイナリログファイル名と復元位置を使用して新しいインスタンスを作成します。

リクエストのデータを使用する前に、次のように置き換えます。

project-id: プロジェクト ID
target-instance-id: ターゲットインスタンス ID
source-instance-id: ソースインスタンス ID
binary-log-file-name: バイナリログファイルの名前
binary-log-position: バイナリログファイル内の位置

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",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

確認したバイナリログファイル名と復元位置を使用して新しいインスタンスを作成します。

リクエストのデータを使用する前に、次のように置き換えます。

project-id: プロジェクト ID
target-instance-id: ターゲットインスタンス ID
source-instance-id: ソースインスタンス ID
binary-log-file-name: バイナリログファイルの名前
binary-log-position: バイナリログファイル内の位置

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",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

リクエストを送信するには、次のいずれかのオプションを開きます。

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

次のような JSON レスポンスが返されます。

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

トラブルシューティング

問題トラブルシューティング

問題	トラブルシューティング
`argument --point-in-time: Failed to parse date/time: Unknown string format: 2021-0928T30:54:03.094; received: 2021-0928T30:54:03.094Z` または `Invalid value at 'body.clone_context.point_in_time' (type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime', Invalid time format: Failed to parse input,`	指定したタイムスタンプは無効です。
`HTTP Error 400: Successful backup required for carrying out the operation was not found.` または `Successful backup required for carrying out the operation was not found. or Time where no backups can be found.`	指定したタイムスタンプは、バックアップの時間またはバイナリログ座標を発見できなかった時間です。

argument --point-in-time: Failed to parse date/time: Unknown string format: 2021-0928T30:54:03.094; received: 2021-0928T30:54:03.094Z

または

Invalid value at 'body.clone_context.point_in_time' (type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime', Invalid time format: Failed to parse input,

指定したタイムスタンプは無効です。

HTTP Error 400: Successful backup required for carrying out the operation was not found.

または

Successful backup required for carrying out the operation was not found. or Time where no backups can be found.

指定したタイムスタンプは、バックアップの時間またはバイナリログ座標を発見できなかった時間です。

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 を使用してトランザクションログの保存場所を切り替えることはできません。
`MySQL transactional logging is not enabled on this instance.`	MySQL では、ポイントインタイムリカバリ（PITR）用のトランザクションログとしてバイナリロギングが使用されます。PITR をサポートするには、MySQL のインスタンスでバイナリロギングを有効にする必要があります。バイナリロギングを有効にする方法の詳細については、PITR を有効にするをご覧ください。
`This command is not supported on replica instances. Run the command on the primary instance instead.`	コマンドを実行するとき、または API リクエストを行うときには、プライマリインスタンスを指定してください。
`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 に使用されるトランザクションログの保存場所を確認するのコマンドを実行します。

次のステップ

クローンのフラグを構成する。

ポイントインタイム リカバリ（PITR）を使用する

PITR 用のログストレージ

ログの保持期間

ログとディスクの使用状況

PITR を有効にする

コンソール

gcloud

Terraform

変更を適用する

Cloud Shell を準備する

ディレクトリを準備する

変更を適用する

変更を削除する

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

タイムスタンプを使用して PITR を実行する

コンソール

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

PITR を無効にする

コンソール

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

PITR に使用されるトランザクション ログの保存場所を確認する

gcloud

トランザクション ログ ストレージを Cloud Storage に切り替える

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

切り替え後のトランザクション ログの保存と構成

トランザクション ログの保持を設定する

コンソール

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

バイナリログの位置を使用して PITR を実行する

始める前に

復元位置を特定する

バイナリログ イベントの位置を使用して PITR を実行する

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

ポイントインタイムリカバリ（PITR）を使用する

PITR に使用されるトランザクションログの保存場所を確認する

トランザクションログストレージを Cloud Storage に切り替える

切り替え後のトランザクションログの保存と構成

トランザクションログの保持を設定する

バイナリログイベントの位置を使用して PITR を実行する