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

このページでは、ポイントインタイム リカバリを使用して Cloud SQL インスタンスを復元する方法について説明します。

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

ポイントインタイム リカバリを有効にする

Google Cloud Console で新しいインスタンスを作成すると、[自動バックアップ] と [ポイントインタイム リカバリを有効にする] の両方が自動的に有効になります。この手順では、既存のインスタンスでポイントインタイム リカバリを有効にします。

コンソール

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

    Cloud SQL の [インスタンス] に移動

  2. ポイントインタイム リカバリを有効にするインスタンスの [その他の操作] メニュー その他の操作アイコン を開き、[編集] をクリックします。
  3. [インスタンスのカスタマイズ] で、[バックアップ] セクションを開きます。
  4. [ポイントインタイム リカバリを有効にする] チェックボックスをオンにします。
  5. [詳細オプション] を開きます。
  6. ログの保持日数を 1~7 で指定します。
  7. [保存] をクリックします。

gcloud

  1. インスタンスの概要を表示します。
    gcloud sql instances describe INSTANCE_NAME
    
  2. backupConfiguration セクションに enabled: false が表示されている場合は、スケジュール バックアップを有効にします。
    gcloud sql instances patch INSTANCE_NAME \
    --backup-start-time=HH:MM
    

    backup-start-time パラメータを UTC±00 タイムゾーンの 24 時間形式で指定します。

  3. ポイントインタイム リカバリを有効にします。
    gcloud sql instances patch INSTANCE_NAME \
    --enable-bin-log
    

    プライマリ インスタンスでポイントインタイム リカバリを有効にする場合は、次のパラメータを追加して、トランザクション ログの保持日数を構成することもできます。

    --retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
    
  4. 変更を確定します。
    gcloud sql instances describe INSTANCE_NAME

    変更が成功すると、backupConfiguration セクションに binaryLogEnabled: true が表示されます。

Terraform

ポイントインタイム リカバリを有効にするには、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"
    }
  }
  deletion_protection =  "true"
}

変更を適用する

Google Cloud プロジェクトで Terraform 構成を適用するには、次の手順を行います。

  1. Cloud Shell を起動します。
  2. Terraform 構成を適用する Google Cloud プロジェクトを設定します。
        export GOOGLE_CLOUD_PROJECT=PROJECT_ID
        
  3. ディレクトリを作成し、そのディレクトリ内で新規ファイルを開きます。ファイル名には .tf 拡張子が必要です(例: main.tf)。
        mkdir DIRECTORY && cd DIRECTORY && nano main.tf
        
  4. サンプルを main.tf にコピーします。
  5. 環境に適用するサンプル パラメータを確認し、変更します。
  6. Ctrl-x を押してから、y を押し、変更を保存します。
  7. Terraform を初期化します。
    terraform init
  8. 構成を確認して、Terraform が作成または更新するリソースが想定どおりであることを確認します。
    terraform plan

    必要に応じて構成を修正します。

  9. 次のコマンドを実行し、プロンプトで「yes」と入力して、Terraform 構成を適用します。
    terraform apply

    Terraform に「Apply complete!」のメッセージが表示されるまで待ちます。

  10. Google Cloud プロジェクトを開いて結果を表示します。Google Cloud コンソールの UI でリソースに移動して、Terraform によって作成または更新されたことを確認します。

変更を削除する

変更を削除するには、次の手順を行います。

  1. 削除の保護を無効にするには、Terraform 構成ファイルで deletion_protection 引数を false に設定します。
    deletion_protection =  "false"
  2. 次のコマンドを実行し、プロンプトで「yes」と入力して、更新された Terraform 構成を適用します。
    terraform apply
  1. 以前に Terraform 構成で適用されたリソースを削除するには、次のコマンドを実行して、プロンプトに「yes」と入力します。

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

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

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

REST v1beta4

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

  • project-id: プロジェクト ID
  • instance-id: インスタンス ID(プライマリまたはレプリカ)
  • start-time「HH:MM」形式の時刻

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/project-id/instances/instance-id

JSON 本文のリクエスト:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "start-time",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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

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

ポイントインタイム リカバリを実行する

コンソール

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

    Cloud SQL の [インスタンス] に移動

  2. 復元するインスタンスの [その他の操作] メニュー(その他の操作アイコン)を開き、[クローン] をクリックします。
  3. 省略可。[クローンの作成] ページで、新しいインスタンスの名前を更新します。
  4. [前の時刻からクローンを作成] を選択します。
  5. ポイントインタイム リカバリ時間を入力します。
  6. [クローンを作成] をクリックします。

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 レスポンスが返されます。

ポイントインタイム リカバリを無効にする

コンソール

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

    Cloud SQL の [インスタンス] に移動

  2. 無効にするインスタンスの [その他の操作] メニュー その他の操作アイコン を開き、[編集] を選択します。
  3. [インスタンスのカスタマイズ] で、[バックアップ] セクションを開きます。
  4. [ポイントインタイム リカバリを有効にする] をクリアします。
  5. [保存] をクリックします。
  6. インスタンスの [概要] ページで、[binaryLogEnabled] が「false」と表示されます。

gcloud

  1. ポイントインタイム リカバリを無効にします。
    gcloud sql instances patch INSTANCE_NAME \
    --no-enable-bin-log
  2. 変更を確定します。
    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
    }
  }
}

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

次のような 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,
      "binaryLogEnabled": false
    }
  }
}

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

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

ディスク使用量とポイントインタイム リカバリ

ポイントインタイム リカバリではバイナリログが使用されます。これらのログは定期的に更新され、保存容量を使用します。バイナリログは、関連する自動バックアップによって自動的に削除されます。これは通常、約 7 日後に発生します。

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

  • インスタンスのストレージ サイズを増やすことはできますが、ディスク使用量のバイナリログ サイズの増加は一時的なものである可能性があります。

  • 予期しないストレージの問題を避けるため、ストレージの自動増量を有効にすることをおすすめします。

  • ログを削除してストレージを復元する場合は、ポイントインタイム リカバリを無効にします。使用されるストレージを減らしても、インスタンスにプロビジョニングされるストレージのサイズは縮小されません。

  • ログは継続的ではなく、1 日 1 回削除されます。ログの保持期間を 2 日に設定すると、少なくとも 2 日間、最大で 3 日間のログが保持されます。指定した日数分のログの保持を保証するために、バックアップの日数は、ログを保持する日数よりも 1 日長く設定することをおすすめします。

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

バイナリログの保持日数(1~7)を設定するには:

コンソール

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

    Cloud SQL の [インスタンス] に移動

  2. トランザクション ログを設定するインスタンスの [その他の操作] メニュー その他の操作アイコン を開き、[編集] を選択します。
  3. [インスタンスのカスタマイズ] で、[バックアップ] セクションを開きます。
  4. [ポイントインタイム リカバリを有効にする] セクションで、[詳細オプション] を開きます。
  5. ログの保持日数を 1~7 で指定します。
  6. [保存] をクリックします。

gcloud

インスタンスを編集して、バイナリログを保持する日数を設定します。

次のように置き換えます。

  • INSTANCE-NAME - トランザクション ログを有効にするインスタンスの名前。
  • DAYS-TO-RETAIN - トランザクション ログの保持日数。有効な範囲は 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 レスポンスが返されます。

バイナリログの位置を使用してポイントインタイム リカバリを実行する

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

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

始める前に

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

リカバリ位置を確認する

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

    そのためには、Cloud Shell またはローカル クライアント マシンを使用します。詳細については、外部アプリケーションの接続オプションをご覧ください。

  2. インスタンスのバイナリ ログファイルを表示します。

    SHOW BINARY LOGS;
    
  3. 最新のバイナリ ログファイルの最初のイベント 100 件を表示します。

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
    

    表示する行数は調整できますが、ファイルのサイズが大きい場合、ファイル内のすべてのイベントが表示されるとは限りません。表示するイベント数が多いと、システムのパフォーマンスに影響します。

  4. 探しているイベントがない場合は、開始位置として表示されている最後の位置を使用して、次のイベントセットを検索します。

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
    
  5. 復元するポイントインタイムをマークするイベントが見つかったら、位置(Pos として表示)とバイナリログ ファイルの名前を記録します。

    バイナリログのファイル名と位置は、ポイントインタイム リカバリで使用する値です。

以下に 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 ステートメントとそれ以降のすべてのオペレーションは、新しいインスタンスには反映されません。

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

gcloud

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

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

    次のように置き換えます。

    • 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 \
  2. 復元オペレーションのステータスを確認するには、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"
    }
  }
}

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

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

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

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

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

トラブルシューティング

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

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.

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

次のステップ