概要
Cloud Spanner のバックアップと復元を使用すると、Cloud Spanner データベースのバックアップをオンデマンドで作成し、論理データの破損の原因となる演算子とアプリケーション エラーから保護できます。バックアップは可用性が高く、暗号化され、作成後の最大 1 年間保持できます。さらに長い保持期間が必要な場合は、データベースをエクスポートすることをおすすめします。
バックアップと復元は、次の方法で使用できます。
- Google Cloud Console の場合
- gcloud コマンドライン ツールの使用
- クライアント ライブラリの使用
- REST または RPC API の使用
論理データの破損のために、Cloud Spanner はポイントインタイム リカバリも備えています。
主な機能
データの整合性: バックアップとは、バックアップの
version_timeにある Cloud Spanner データベースの外部一貫性コピーのことです。レプリケーション: バックアップはソース データベースと同じインスタンスに存在し、同じ地理的な場所に複製されます。リージョン インスタンスの場合、バックアップのコピーは 3 つの読み取り / 書き込みゾーンのそれぞれに保存されます。マルチリージョン インスタンスの場合、コピーは読み取り / 書き込みレプリカまたは読み取り専用レプリカが含まれるすべてのゾーンに保存されます。
自動有効期限: すべてのバックアップには、ユーザーが指定する有効期限があります。これは、いつ自動的に削除されるかを決定します。
バックアップと復元、インポートとエクスポートのいずれかを選択する
Cloud Spanner のインポートとエクスポートでは、バックアップと復元と同様のユースケースが提供されます。次の表は、どちらを使用するかを決定する際に役立つように、これらの類似点と相違点を示しています。
| バックアップと復元 | インポートとエクスポート | |
|---|---|---|
| データの整合性 | バックアップとエクスポートされたデータベースの両方が、トランザクションと外部一貫性を備えています。 | |
| パフォーマンスへの影響 | データベースのパフォーマンスへの影響を最小限に抑えるため、どちらも高優先度で実行されることはありません。エクスポートは中優先度 で実行され、バックアップは低優先度で実行されます。詳細については、タスク優先度をご覧ください。 | |
| ストレージ形式 | 高速での復元用に設計された独自の暗号化された形式を使用します。 | CSV とAvro の両方のファイル形式がサポートされます。 |
| ポータビリティ | バックアップはソース データベースと同じインスタンスに存在し、移動はできません。 バックアップと同じインスタンス構成で、プロジェクト内の任意のインスタンスにデータベースを復元できます。 |
エクスポートされたデータベースは Google Cloud Storage に存在し、CSV または Avro をサポートしている任意のシステムにデータを移行できます。 |
| 保持 | バックアップは最長 1 年間保持できます。 | エクスポートされたデータベースは Cloud Storage に保存され、デフォルトでは削除されるまで保持されます。ライフサイクルと保持ポリシーをカスタマイズできます。 |
| 課金 | バックアップは、単位時間あたりの使用容量に基づいて Cloud Spanner プロジェクトに対して課金されます。詳しくは、課金セクションをご覧ください。 | インポートとエクスポートの課金は、Google Cloud Storage と Dataflow を使用しているため、より複雑になります。詳細については、データベースのエクスポートとインポートの料金をご覧ください。 |
| 復元時間 | 復元は、復元と最適化の 2 つのオペレーションで行われます。復元オペレーションでは、データをコピーすることなくデータベースでバックアップが直接マウントされるため、最初のバイト転送時間が短縮されます。復元オペレーションが完了すると、データベースを使用できるようになりますが、最適化中は読み取りレイテンシが若干高くなる場合があります。詳しくは、復元の仕組みをご覧ください。 | インポートには時間がかかります。すべてのデータがデータベースに書き込まれるのを待つ必要があります。 |
バックアップの仕組み
コンテンツ
ユーザーは任意の Cloud Spanner データベースのバックアップを作成できます。こうしたバックアップは、すべてのデータ（スキーマとセカンダリ インデックスを含む）が、バックアップの version_time のデータベースに含まれているという意味で完全です。version_time より後のデータまたはスキーマに対する変更は、バックアップには含まれません。バックアップには Identity and Access Management（IAM）ポリシーなどのデータベース メタデータは含まれません。
暗号化
データベースなどの Cloud Spanner バックアップは、CMEK または Google が管理する暗号化によって保護できます。デフォルトでは、バックアップはデータベースと同じ暗号化構成を使用しますが、バックアップ作成時に別の暗号化構成を指定すると、この動作をオーバーライドできます。CMEK が有効になっているバックアップの場合、バックアップの作成時に KMS 鍵のプライマリ バージョンを使用して暗号化されます。バックアップが作成されると、KMS 鍵がローテーションされても、その鍵と鍵バージョンを変更することはできません。詳細については、CMEK 対応バックアップの作成をご覧ください。
作成プロセス
バックアップを作成する際に、ソース データベース、バックアップ リソースの名前、有効期限（バックアップの作成時から最長 1 年）を指定する必要があります。必要に応じて、version_time を指定することもできます。これを使用して、前の時点でのデータベースをバックアップできます。version_time フィールドは通常、複数のデータベースのバックアップを同期させる、またはポイントインタイム リカバリを使用してデータを復元する目的に使用されます。version_time が指定されていない場合、バックアップの create_time に設定されます。バックアップの進行状況を追跡するために、バックアップ リソースと長時間実行バックアップ オペレーションが作成されます。
バックアップの外部整合性を確保するために、Cloud Spanner によって、作成時にデータベースのコンテンツが固定されます。これにより、バックアップ オペレーションの実行中は、ガベージ コレクション システムによって関連するデータ値が削除されることが回避されます。その後、インスタンス内のすべてのゾーンでデータのコピーが開始されます。ゾーンが一時的に使用不可になっている場合、そのゾーンがオンラインに戻って完了するまでバックアップは完了しません。オペレーションが完了したら、すぐにバックアップを復元できます。
リソース階層
バックアップは Cloud Spanner のリソースです。各バックアップ リソースは、リソース階層内のソース データベースと同じインスタンスごとにまとめられ、リソースパスは projects/<project>/instances/<instance>/backups/<backup> 形式になります。ソース データベースが削除された後もバックアップは存在し続けますが、親インスタンスより長く存続することはできません。バックアップがある場合は、バックアップが誤って削除されないようにするために、Cloud Spanner インスタンスを削除できません。インスタンスを削除する場合は、バックアップを復元し、復元したデータベースをエクスポートしてから、バックアップとインスタンスを削除することをおすすめします。
バックアップの時間とパフォーマンス
バックアップの作成にかかる時間はさまざまな要因によって異なりますが、主にデータベースのサイズとノードの数によって決まります。バックアップにかかる時間を短縮する必要がある場合は、ノード数を増やすことによって実現できますが、ノード数の変更はその後のバックアップに反映されることを念頭に置いてください。
バックアップの作成にはアイドル状態の CPU も使用するため、CPU 使用率が推奨ガイドラインの範囲内であることを確認してください。CPU が過負荷になると、バックアップにかかる時間が非常に長くなり、データベースのレイテンシに悪影響を与える可能性があります。
インスタンス内の CPU は、インスタンス内のすべての進行中のバックアップで共有されます。同じインスタンスで複数のデータベースのバックアップを同時に作成すると、バックアップにかかる時間が長くなる可能性があります。
復元の仕組み
復元時に、ソース バックアップと新しいターゲット データベースを指定する必要があります。既存のデータベースに復元することはできません。新しいデータベースがバックアップと同じプロジェクトに存在し、バックアップと同じインスタンス構成でインスタンスに存在している必要があります。たとえば、us-west3 が構成されたインスタンスにバックアップが存在している場合、us-west3 も構成されているプロジェクト内の任意のインスタンスに復元できます。インスタンスのノード数を同じにする必要はありません。復元されたデータベースには、バックアップの create_time にある元のデータベースのすべてのデータとスキーマが含まれます。復元されたデータベースが含まれているインスタンスから継承されたものを除き、IAM 権限はありません。復元が完了したら、適切な IAM 権限を適用する必要があります。データベースでインスタンスのリージョンとゾーンの大部分のクォーラムが使用可能である限り、復元プロセスは高可用性を実現するように設計されます。
CMEK を有効化したバックアップを復元するには、Cloud Spanner が鍵と鍵バージョンの両方を利用できることが必要です。デフォルトでは、復元されたデータベースはバックアップと同じ暗号化構成を使用します。この動作をオーバーライドするには、データベースを復元するときに別の暗号化構成を指定します。詳しくは、CMEK を有効化したバックアップから復元するをご覧ください。
復元されたデータベースの 3 つの States 間での移行は、2 つのオペレーションによってトラッキングされることを理解しておく必要があります。
CREATING状態: 復元を開始すると、新しいデータベースと長時間実行データベース オペレーションがRestoreDatabaseMetadataを使用して作成され、復元の進捗状況がトラッキングされます。新しいデータベースが開始され、CREATING状態のままになります。つまり、復元オペレーションが完了するまで使用できません。復元時間を短縮するために（通常は 10 分以内）、復元オペレーションでは、バックアップ内のファイルをデータベースにコピーせずにマウントします。READY_OPTIMIZING状態: 復元オペレーションが完了すると、データベースがREADY_OPTIMIZING状態に移行します。この状態では、データベースは使用可能ですが、データベースでバックアップからデータを読み取る際に、若干の読み取りレイテンシが発生する可能性があります。データベースの復元や最適化に使用されている間にバックアップを削除しようとすると、失敗します。復元オペレーションが完了すると、
OptimizeRestoredDatabaseMetadataでの別の長時間実行データベース オペレーションが発生し、最適化の進捗状況がトラッキングされます。最適化オペレーションで、バックアップからデータベースにデータがコピーされます。最適化プロセスにかかる時間を短縮するには、インスタンスにノードを追加します。READY状態: 最適化オペレーションが完了すると、データベースがREADY状態に移行します。この時点では、復元されたデータベースのパフォーマンスが高く、バックアップを参照しなくなります。
復元 CREATING 状態のインスタンスに格納できるデータベースは 1 つだけです。復元されたデータベースが READY_OPTIMIZING または READY 状態に移行するまで、別のバックアップをインスタンスに復元することはできません。
課金
料金は、単位時間あたりのバックアップで使用されるストレージの量に基づいて課金されます。バックアップ オペレーションが完了すると課金が開始され、バックアップが削除されるまで継続されます。バックアップからの復元は無料です。
バックアップは保存され、料金は別途請求されます。バックアップ ストレージは、データベース ストレージの料金やデータベースのストレージ制限には影響しません。
作成が完了したバックアップには、最低でも 24 時間分の料金が発生します。バックアップを作成し、完了してから 1 分後に削除した場合でも、24 時間分の料金が請求されます。
バックアップ コストの詳細については、Cloud Spanner の料金ページをご覧ください。
アクセス制御（IAM）
IAM では、バックアップと復元されたデータベースを含む Cloud Spanner リソースへのアクセスを制御できます。IAM、ロール、権限を初めて使用する場合は、IAM の概要で概要を確認してください。
バックアップ リソースは、Cloud Spanner リソース階層でインスタンスごとにまとめられます。プロジェクト レベルまたはインスタンス レベルで IAM ポリシーを適用することをおすすめします。より細かく制御する必要がある場合は、バックアップ レベルとデータベース レベルでも IAM ポリシーを適用できますが、これは複雑であるため、おすすめしません。 バックアップには IAM ポリシーなどのデータベース メタデータは含まれないため、データベースを復元すると、データベースは最初に親インスタンスからポリシーを継承します。
このセクションでは、バックアップと復元にアクセスできる事前定義ロールについて説明します。
以下のロールは、バックアップと復元専用に設計されています。
spanner.backupAdmin: バックアップの作成、表示、更新、削除のためのアクセス権があります。このロールでは、バックアップの IAM ポリシーの表示と管理も可能です。このロールでは。バックアップからデータベースを復元することはできません。spanner.restoreAdmin: バックアップからデータベースを復元するためのアクセス権があります。バックアップを別のインスタンスに復元する必要がある場合は、このロールをプロジェクト レベルで、または両方のインスタンスに適用します。このロールではバックアップを作成できません。spanner.backupWriter: バックアップを作成できますが、更新や削除はできません。このロールは、バックアップの作成を自動化するスクリプトで使用されます。
次のロールでは、バックアップと復元にもアクセスできます。
spanner.admin: バックアップと復元への完全アクセス権があります。このロールには、すべての Cloud Spanner リソースへの完全アクセス権があります。owner: バックアップと復元への完全アクセス権があります。editor: バックアップと復元への完全アクセス権があります。viewer: バックアップ、バックアップ オペレーション、復元オペレーションを表示できます。このロールでは、バックアップの作成、更新、削除、復元は行えません。
詳細については、Cloud Spanner IAM をご覧ください。