インスタンスの復元について

MySQL | PostgreSQL | SQL Server

このページでは、バックアップからのインスタンスの復元やポイントインタイムリカバリ（PITR）の実行の前に確認すべき情報について説明します。

復元時の動作

インスタンスを復元すると、プライマリインスタンスから次のデータが新しいインスタンスに復元されます。

データベース
ユーザー

復元オペレーションを行うと、インスタンスが再起動されます。

ポイントインタイムリカバリ（PITR）

ポイントインタイムリカバリ（PITR）を利用すると、インスタンスを特定の時点の状態に復元できます。たとえば、エラーによってデータが失われた場合に、そのエラーが発生する前の状態にデータベースを復元できます。

PITR は常に新しいインスタンスを作成します。既存のインスタンスに PITR を実行することはできません。新しいインスタンスは、クローン作成と同様に、ソースインスタンスの設定を継承します。

Cloud SQL は PITR にトランザクションログを使用します。インスタンスで PITR を有効にして、バックアップからインスタンスを復元すると、Cloud SQL は復元されたインスタンスから PITR を使用できるトランザクションログを削除します。

インスタンスのログがディスクではなく Cloud Storage に保存されるようにするには、次の操作を行います。

インスタンスのネットワークアーキテクチャを確認します。インスタンスが古いネットワークアーキテクチャを使用している場合は、新しいネットワークアーキテクチャにアップグレードします。
ディスク上のログのサイズが原因でインスタンスのパフォーマンスの問題が発生している場合は、PITR を無効にしてから再度有効にします。

PITR を実行する手順については、ポイントインタイムリカバリ（PITR）を使用するをご覧ください。

使用不能なインスタンスを復元する

PITR を使用すると、使用不能の Cloud SQL インスタンスを復元できます。PITR の目標復旧時点（RPO）は一般的に 5 分以下です。

インスタンスが使用不能になった場合は、API を使用して、インスタンスを復元して、その時間まで復元できる直近の時間を確認できます。インスタンスが構成されているゾーンにアクセスできない場合は、優先ゾーンの値を指定してインスタンスを別のプライマリゾーンまたはセカンダリゾーンに復元できます。

Cloud SQL インスタンスが午後 4 時（EST）に利用できなくなったとします。最新の復元時刻が午後 3 時 55 分（EST）であれば、この時点までインスタンスを復元できます。

復元の実行についての全般的なヒント

バックアップから同じインスタンスや別のインスタンスにインスタンスを復元する場合は、次の点に留意してください。

復元オペレーションは、ターゲットインスタンスのすべてのデータを上書きします。
復元オペレーション中は既存の接続が失われるため、ターゲットインスタンスは接続に使用できません。
リードレプリカがあるインスタンスに復元する場合は、すべてのレプリカを削除し、復元オペレーションの完了後に再作成する必要があります。
復元オペレーションによってインスタンスが再起動されます。

復元する方法の詳細については、次のリンク先をご覧ください。

インスタンスの復元

別のインスタンスへの復元のヒントと要件

別のインスタンスにバックアップを復元する場合は、次の制限やベストプラクティスに留意してください。

ターゲットインスタンスのデータベースは、バックアップの取得元であるインスタンスのデータベースと同じバージョン、同じエディションである必要があります。
Cloud SQL は常に、ターゲットインスタンスのストレージ容量を、構成されたディスクとバックアップディスクの両方のサイズの最大値に設定します。バックアップディスクは、バックアップ取得時のディスクのサイズになります。
ターゲットインスタンスのストレージ容量は、バックアップされるインスタンスの容量と同じかそれ以上である必要があります。使用中のストレージ容量は関係ありません。インスタンスのストレージ容量は、コンソールの Cloud SQL インスタンスページで確認できます。この要件は、単一のデータベースの PITR を実行するかどうかに関係なく適用されます。
ターゲットインスタンスは RUNNABLE の状態であることが必要です。
ターゲットインスタンスは、バックアップを作成したインスタンスとコアの数やメモリの量が異なっていても構いません。
ターゲットインスタンスは、ソースインスタンスとは異なるリージョンに存在する場合があります。
停止中でも、特定のプロジェクトのバックアップリストを取得できます。停止時にバックアップを表示するをご覧ください。

復元のレート制限

1 つのプロジェクト、1 つのリージョン、1 つのインスタンスにつき、30 分ごとに最大 3 つの復元オペレーションが許可されます。復元オペレーションが失敗した場合、この割り当てにカウントされません。上限に達するとオペレーションは失敗し、オペレーションの再実行が可能となるタイミングを示すエラーメッセージが表示されます。

では、Cloud SQL が復元のレート制限をどのように実行しているのか見てみましょう。

Cloud SQL は、バケットからのトークンを使用して、一度に実行可能な復元オペレーションの数を決定します。各バックアップには、ターゲットプロジェクトとターゲットリージョンごとに 1 つのバケットがあります。同じリージョンにある場合、同じプロジェクトのターゲットインスタンスは 1 つのバケットを共有します。各バケットには、復元オペレーションに使用できるトークンが最大で 3 つあります。10 分ごとに新しいトークンがバケットに追加されます。バケットがいっぱいの場合、トークンはオーバーフローします。

復元オペレーションのたびに、バケットからトークンが付与されます。オペレーションが成功すると、バケットからトークンが削除されます。失敗した場合、トークンがバケットに返されます。次の図は、この仕組みを示しています。

トークンの仕組み

たとえば、次の図では、Backup1、Backup2、Backup3 が同じソースインスタンスのバックアップです。

復元オペレーションのレート制限のトークン

各バックアップ（Backup1、Backup2、Backup3）には、リージョン A のプロジェクト 1 の異なるインスタンスをターゲットとする復元オペレーション用のトークンバケットがあります（Bucket11A、Bucket21A、Bucket31A）。各バックアップには独自のバケットがあるため、30 分ごとに各バックアップを同じインスタンスに 3 回、復元できます。
各バックアップには、プロジェクトとリージョンごとに 1 つのバケットがあります。たとえば、リージョンに 5 つのプロジェクトがある場合、そのリージョンにバックアップ用のバケットが 5 つあります（プロジェクトごとに 1 つずつ）。上の図では、リージョン A にプロジェクト 1 とプロジェクト n の 2 つのプロジェクトがあります。
- Backup1 には、リージョン A の復元オペレーション用に 2 つのトークンバケットがあります。1 つのバケットはプロジェクト 1 用（Bucket11A）、もう 1 つのバケットはプロジェクト n 用（Bucket1nA）です。
- 同様に、Backup3 には、リージョン A での復元オペレーション用の 2 つのバケットがあります。1 つはプロジェクト 1 用（Bucket31A）、もう 1 つはプロジェクト n 用（Bucket3nA）です。
同じターゲットプロジェクトと同じターゲットリージョン内のすべてのインスタンスが 1 つのバケットを共有するため、Backup3 にはリージョン B にプロジェクト 1 用のパケットが 1 つあります。