ポイントインタイム リカバリ

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

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

始める前に

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

  • インスタンスでバイナリログとバックアップが有効になっていて、復元するイベントの前の最後のバックアップ以降、インスタンスでバイナリログが継続されている。詳細については、バイナリログを有効にするをご覧ください。

  • バイナリログ ファイル名と復元に使用するイベントの位置(このイベントとその後のすべてのイベントは新しいインスタンスには反映されません)。詳細については、バイナリログの位置を識別するをご覧ください。

    バイナリ ログファイルと位置を特定したら、ポイントインタイム リカバリを実行できます。

バイナリログの有効化

Console

  1. Google Cloud Console の Cloud SQL インスタンス ページに移動します。

    [Cloud SQL インスタンス] ページに移動

  2. ポイントインタイム リカバリを有効にするインスタンスを選択します。
  3. [編集] をクリックします。
  4. [バックアップ、復元、高可用性] セクションで、[バックアップを自動化する] を選択し、[ポイントインタイム リカバリを有効にする] を選択します。
  5. [保存] をクリックします。
  6. インスタンスの [インスタンスの詳細] ページで、[binaryLogEnabled] が true と表示されます。

gcloud

  1. インスタンスの詳細を表示します。
    gcloud sql instances describe [INSTANCE_NAME]
    
  2. backupConfigurationenabled: 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
    
    
  4. 変更を確定します。
    gcloud sql instances describe [INSTANCE_NAME]
    

    backupConfiguration で、binaryLogEnabled: true を探します。

REST

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

  • project-id: プロジェクト ID
  • instance-id: インスタンス ID
  • start-time「HH:MM」形式の時刻

HTTP メソッドと URL:

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

JSON 本文のリクエスト:

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

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

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

ポイントインタイム リカバリの実行

Console

  1. Google Cloud Console の Cloud SQL インスタンス ページに移動します。

    [Cloud SQL インスタンス] ページに移動

  2. 復元するインスタンスの [その他の操作] メニュー(その他アイコン)を開き、[クローンを作成] をクリックします。
  3. [クローンの作成] ウィンドウで、必要に応じて新しいインスタンスの名前を更新します。
  4. [前の時刻からクローンを作成] を選択します。
  5. [バイナリログ ファイル名] に、以前に特定したバイナリログの名前を入力します。
  6. イベントの位置を [復元位置] に入力します。
  7. [クローンを作成] をクリックします。

gcloud

  1. 確認したバイナリログ ファイル名と復元位置を使用して新しいインスタンスを作成します。
    gcloud sql instances clone [SOURCE_INSTANCE_NAME] [NEW_INSTANCE_NAME] \
           --bin-log-file-name=[BINLOG_FILE_NAME] --bin-log-position=[POSITION]
    

    たとえば、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 が返されます。

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

REST

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

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

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

HTTP メソッドと URL:

POST https://www.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 レスポンスが返されます。

バイナリログの無効化

Console

  1. Google Cloud Console の 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

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

  • project-id: プロジェクト ID
  • instance-id: インスタンス ID

HTTP メソッドと URL:

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

JSON 本文のリクエスト:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

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

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

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

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

バイナリログのサイズが原因でインスタンスに問題が起きている場合、インスタンスのストレージ サイズを大きくすることはできますが、ディスク使用量のバイナリログ サイズが大きくなるのはあくまで一時的です。予期しないストレージの問題を回避するには、PITR の使用時にストレージの自動増量を有効にすることをおすすめします。

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