このページでは、ポイントインタイム リカバリを使用してプライマリ Cloud SQL インスタンスを復元する方法について説明します。
ポイントインタイム リカバリの詳細については、ポイントインタイム リカバリをご覧ください。
ポイントインタイム リカバリ用のログストレージ
ポイントインタイム リカバリではバイナリログが使用されます。ポイントインタイム リカバリが有効になっている新しい Cloud SQL インスタンス、またはポイントインタイム リカバリが有効になっている既存のインスタンスの場合、ログはディスク上ではなく同じリージョンの Cloud Storage に保存されます。新しいログは定期的に生成され、保存容量を使用します。バイナリログは、関連する自動バックアップによって自動的に削除されます。これは通常、transactionLogRetentionDays に設定された値に達した後に行われます。これは、Cloud SQL がポイントインタイム リカバリのために保持するトランザクション ログの日数です。Cloud SQL Enterprise Plus エディションの場合、保持されるトランザクション ログの日数は 1~35 に設定できます。Cloud SQL Enterprise エディションの場合、値は 1~7 に設定できます。
ポイントインタイム リカバリの詳細については、ポイントインタイム リカバリをご覧ください。
バイナリログのサイズが原因でインスタンスに問題が発生している場合:
インスタンスのストレージ サイズを増やすことはできますが、ディスク使用量のバイナリログ サイズの増加は一時的なものである可能性があります。
予期しないストレージの問題を避けるため、ストレージの自動増量を有効にすることをおすすめします。
ログを削除してストレージを復元する場合は、ポイントインタイム リカバリを無効にします。使用するストレージを減らしても、インスタンスにプロビジョニングされるディスクのサイズは縮小されません。
ログは継続的ではなく、1 日 1 回削除されます。ログの保持期間を 2 日に設定すると、少なくとも 2 日間、最大で 3 日間のログが保持されます。指定した日数分のログの保持を保証するために、バックアップの日数は、ログを保持する日数よりも 1 日長く設定することをおすすめします。
ポイントインタイム リカバリを有効にする
Google Cloud Console で新しいインスタンスを作成すると、[自動バックアップ] と [ポイントインタイム リカバリを有効にする] の両方が自動的に有効になります。次の手順では、既存のプライマリ インスタンスでポイントインタイム リカバリを有効にします。
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- ポイントインタイム リカバリを有効にするインスタンスの [その他の操作] メニュー
を開き、[編集] をクリックします。
- [インスタンスのカスタマイズ] で、[データ保護] セクションを開きます。
- [ポイントインタイム リカバリを有効にする] チェックボックスをオンにします。
- [詳細オプション] を開きます。
- ログを保持する日数を 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 時間形式で指定します。- ポイントインタイム リカバリを有効にします。
gcloud sql instances patch INSTANCE_NAME \ --enable-bin-log
プライマリ インスタンスでポイントインタイム リカバリを有効にする場合は、次のパラメータを追加して、トランザクション ログの保持日数を構成することもできます。
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- 変更を確定します。
gcloud sql instances describe INSTANCE_NAME
変更が成功すると、
backupConfiguration
セクションにbinaryLogEnabled: true
が表示されます。
Terraform
ポイントインタイム リカバリを有効にするには、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
-
次のコマンドを実行しています。プロンプトで「
yes
」と入力して、以前に Terraform 構成で適用されたリソースを削除します。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 レスポンスが返されます。
ポイントインタイム リカバリを実行する
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- 復元するインスタンスの [その他の操作] メニュー(
)を開き、[クローンの作成] をクリックします。
- 必要に応じて、[クローンの作成] ページで新しいクローンの ID を更新します。
- 過去の時点からクローンを作成を選択
- ポイントインタイム リカバリ時間を入力します。
- [クローンを作成] をクリックします。
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 レスポンスが返されます。
ポイントインタイム リカバリを無効にする
コンソール
-
Google Cloud コンソールで 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 } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような 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 レスポンスが返されます。
トランザクション ログの保持を設定する
バイナリログの保持日数を設定するには:
コンソール
-
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(デフォルト: 15)、Cloud SQL Enterprise Edition の場合は 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 リファレンスのバイナリログを使用したポイントインタイム リカバリをご覧ください。
始める前に
このタスクを行う前に、次のことを確認する必要があります。
インスタンスでバイナリ ロギングとバックアップが有効になっていて、復元するイベントの前の最後のバックアップ以降、インスタンスでバイナリ ロギングが継続されている。詳細については、バイナリ ロギングを有効にするをご覧ください。
バイナリログ ファイル名と復元に使用するイベントの位置(このイベントとその後のすべてのイベントは新しいインスタンスには反映されません)。詳細については、バイナリログの位置を特定するをご覧ください。
バイナリログのファイル名と位置を確認したら、バイナリログ イベントの位置を使用してポイントインタイム リカバリを実行できます。
リカバリ位置を確認する
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
として表示)とバイナリログ ファイルの名前を記録します。バイナリログのファイル名と位置は、ポイントインタイム リカバリで使用する値です。
以下に 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
コマンドを使用します。
-
バイナリログのファイル名と復元位置を使用して新しいインスタンスを作成します。
次のように置き換えます。
- 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" } } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような 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 レスポンスが返されます。
トラブルシューティング
問題 | トラブルシューティング |
---|---|
または
|
指定したタイムスタンプは無効です。 |
または
|
指定したタイムスタンプは、バックアップの時間またはバイナリログ座標を発見できなかった時間です。 |
次のステップ
- クローンのフラグを構成する。