このページでは、バックアップからのインスタンスの復元やポイントインタイム リカバリ（PITR）の実行の前に確認すべき情報について説明します。
復元時の動作
Cloud SQL Enterprise エディションと Cloud SQL Enterprise Plus エディションでは、バックアップからインスタンスを復元できます。異なるエディションのインスタンス間でバックアップを復元することもできます。
インスタンスを復元すると、プライマリ インスタンスから次のデータが新しいインスタンスに復元されます。
- データベース
- ユーザー
復元オペレーションによってインスタンスは再起動されます。
ポイントインタイム リカバリ
ポイントインタイム リカバリにより、インスタンスを特定のポイントインタイムに復旧できます。たとえば、エラーによってデータが失われた場合、エラーが発生する前の状態にデータベースを復旧できます。
ポイントインタイム リカバリは、常に新しいインスタンスを作成します。既存のインスタンスには、ポイントインタイム リカバリを実行できません。新しいインスタンスは、クローン作成と同様に、ソース インスタンスの設定を継承します。
Cloud SQL インスタンスを作成すると、デフォルトでポイントインタイム リカバリが有効になります。ポイントインタイム リカバリでは、write-ahead log 書き込み（WAL）のアーカイブを使用します。デフォルトでは、Cloud SQL Enterprise Plus エディションのインスタンスではポイントインタイム リカバリが有効になっています。これらのインスタンスはすべて、指定したログ保持期間の間、Cloud Storage に WAL ログを保存します。
2023 年 1 月 9 日、Google は、ポイントインタイム リカバリ用 WAL ログの Cloud Storage への保存を開始しました。Cloud SQL Enterprise エディションのインスタンスの場合、ポイントインタイム リカバリには次の条件が適用されます。
- このリリース後にポイントインタイム リカバリを有効にして作成された新しいインスタンスは、指定したログ保持期間の間、Cloud Storage にログを保存します。
- このリリース後にポイントインタイム リカバリを有効にした既存のインスタンスも、Cloud Storage にログが保存されます。
今回のリリース前にポイントインタイム リカバリを有効にしていた既存のインスタンスのログは、引き続きディスクに保存されます。
psql や pgAdmin などの PostgreSQL クライアントを使用してインスタンスのデータベースに接続したら、show archive_command を実行します。WAL が Cloud Storage にアーカイブされている場合は、-async_archive -remote_storage が表示されます。
ログが Cloud Storage に保存されている場合、Cloud SQL は 5 分以内にログをアップロードします。その結果、Cloud SQL インスタンスがアクセス可能な場合、インスタンスを直近の時間に復元できます。ただし、インスタンスが利用できない場合、目標復旧時点は通常 5 分以内です。インスタンスを復元してその時点まで復元できる直近の時間を確認するために、API を使用します。
ポイントインタイム リカバリで使用される write-ahead log は、関連する自動バックアップによって自動的に削除されます。これは通常、transactionLogRetentionDays に設定された値に達すると行われます。これは、ポイントインタイム リカバリのために Cloud SQL が保持するトランザクション ログの日数です。Cloud SQL Enterprise Plus エディションの場合は 1～35、Cloud SQL Enterprise エディションの場合は 1～7 です。
ポイントインタイム リカバリを有効にする前に Cloud SQL インスタンスでバックアップを復元すると、ポイントインタイム リカバリの運用を可能にする WAL ログが失われます。
write-ahead log が Cloud Storage に保存されているインスタンスの場合、ログはプライマリ インスタンスと同じリージョンに保存されます。このログストレージ（ポイントインタイム リカバリの最大時間である 7 日間まで）では、インスタンスごとの追加コストは発生しません。
インスタンスでポイントインタイム リカバリが有効になっていて、ディスク上のログ先行書き込みのサイズが原因でインスタンスに問題が発生している場合は、ポイントインタイム リカバリを無効にして再度有効にすることで、新しいログがインスタンスと同じリージョンの Cloud Storage に保存されます。これにより、既存のログ先行書き込みが削除されるため、ポイントインタイム リカバリを再度有効にした時点よりも前のポイントインタイム リカバリを行うことはできません。ただし、ディスクサイズは変わりません。
ポイントインタイム リカバリを実行する手順については、ポイントインタイム リカバリを実行するをご覧ください。
使用不能なインスタンスを復元する
ポイントインタイム リカバリを使用して、利用できない Cloud SQL インスタンスを復元できます。ポイントインタイム リカバリは通常、5 分以下の目標復旧時点（RPO）を提供します。
インスタンスが使用不能になった場合は、API を使用して、インスタンスを復元して、その時間まで復元できる直近の時間を確認できます。インスタンスが構成されているゾーンにアクセスできない場合は、別のゾーンにインスタンスのクローンを作成できます。
Cloud SQL インスタンスが午後 4 時（EST）に利用できなくなったとします。最新の復元時刻が午後 3 時 55 分（EST）であれば、この時点までインスタンスを復元できます。
復元の実行についての全般的なヒント
バックアップから同じインスタンスや別のインスタンスにインスタンスを復元する場合は、次の点に留意してください。
- 復元オペレーションは、ターゲット インスタンスのすべてのデータを上書きします。
- 復元オペレーション中は既存の接続が失われるため、ターゲット インスタンスは接続に使用できません。
- リードレプリカがあるインスタンスに復元する場合は、すべてのレプリカを削除し、復元オペレーションの完了後に再作成する必要があります。
- 復元オペレーションによってインスタンスが再起動されます。
復元する方法の詳細については、次のリンク先をご覧ください。
別のインスタンスへの復元のヒントと要件
別のインスタンスにバックアップを復元する場合は、次の制限やベスト プラクティスに留意してください。
ターゲット インスタンスのデータベースは、バックアップの取得元であるインスタンスのデータベースと同じバージョン、同じエディションである必要があります。
Cloud SQL は、ターゲット インスタンスのストレージ容量を、構成されたディスクとバックアップ ディスクの両方のサイズの最大値に常に設定します。バックアップ ディスクは、バックアップ取得時のディスクのサイズです。
ターゲット インスタンスのストレージ容量は、バックアップされるインスタンスの容量と同じかそれ以上である必要があります。使用中のストレージ容量は関係ありません。インスタンスのストレージ容量は、コンソールの Cloud SQL インスタンス ページで確認できます。
ターゲット インスタンスは
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 つあります。