バックアップと復元

概要

Cloud Spanner のバックアップと復元を使用すると、Cloud Spanner データベースのバックアップをオンデマンドで作成し、論理データの破損の原因となる演算子とアプリケーション エラーから保護できます。バックアップは可用性が高く、暗号化され、作成後の最大 1 年間保持できます。さらに長い保持期間が必要な場合は、データベースをエクスポートすることをおすすめします。

バックアップと復元は、次の方法で使用できます。

主な機能

  • データの整合性: バックアップとは、バックアップの create_time にある Cloud Spanner データベースの外部一貫性コピーのことです。

  • レプリケーション: バックアップはソース データベースと同じインスタンスに存在し、同じ地理的な場所に複製されます。リージョン インスタンスの場合、バックアップのコピーは 3 つの読み取り / 書き込みゾーンのそれぞれに保存されます。マルチリージョン インスタンスの場合、コピーは読み取り / 書き込みレプリカまたは読み取り専用レプリカが含まれるすべてのゾーンに保存されます。

  • 自動有効期限: すべてのバックアップには、ユーザーが指定する有効期限があります。これは、いつ自動的に削除されるかを決定します。

バックアップと復元、インポートとエクスポートのいずれかを選択する

Cloud Spanner のインポートエクスポートでは、バックアップと復元と同様のユースケースが提供されます。次の表は、どちらを使用するかを決定する際に役立つように、これらの類似点と相違点を示しています。

バックアップと復元インポートとエクスポート
データの整合性 バックアップとエクスポートされたデータベースの両方が、トランザクションと外部一貫性を備えています。
パフォーマンスへの影響 どちらも優先度を低く設定して、データベースのパフォーマンスへの影響を最小限に抑えます。エクスポートでは優先度の低いユーザー CPU が使用されますが、バックアップでは優先度の低いシステム CPU が使用されます。詳細については、タスク優先度をご覧ください。
ストレージ形式 高速での復元用に設計された独自の暗号化された形式を使用します。 CSV とAvro の両方のファイル形式がサポートされます。
ポータビリティ バックアップはソース データベースと同じインスタンスに存在し、移動はできません。

バックアップと同じインスタンス構成で、プロジェクト内の任意のインスタンスにデータベースを復元できます。
エクスポートされたデータベースは Google Cloud Storage に存在し、CSV または Avro をサポートしている任意のシステムにデータを移行できます。
保持 バックアップは最長 1 年間保持できます。 エクスポートされたデータベースは Cloud Storage に保存され、デフォルトでは削除されるまで保持されます。ライフサイクル保持ポリシーをカスタマイズできます。
課金 バックアップは、単位時間あたりの使用容量に基づいて Cloud Spanner プロジェクトに対して課金されます。詳しくは、課金セクションをご覧ください。 インポートとエクスポートの課金は、Google Cloud StorageDataflow を使用しているため、より複雑になります。詳細については、データベースのエクスポートとインポートの料金をご覧ください。
復元時間 復元は、復元と最適化の 2 つのオペレーションで行われます。復元オペレーションでは、データをコピーすることなくデータベースでバックアップが直接マウントされるため、最初のバイト転送時間が短縮されます。復元オペレーションが完了すると、データベースを使用できるようになりますが、最適化中は読み取りレイテンシが若干高くなる場合があります。詳しくは、復元の仕組みをご覧ください。 インポートには時間がかかります。すべてのデータがデータベースに書き込まれるのを待つ必要があります。

バックアップの仕組み

コンテンツ

ユーザーは任意の Cloud Spanner データベースのバックアップを作成できます。こうしたバックアップは、バックアップの create_time にあるデータベースにすべてのデータ(スキーマとセカンダリ インデックスを含む)が含まれているという意味で完全です。バックアップの作成開始後にデータやスキーマに加えた変更は、バックアップに含まれません。バックアップには Identity and Access Management(IAM)ポリシーなどのデータベース メタデータは含まれません。

作成プロセス

バックアップを作成する際に、ソース データベース、バックアップ リソースの名前、有効期限(バックアップの作成時から最長 1 年)を指定する必要があります。バックアップの進行状況を追跡するために、バックアップ リソースと長時間実行バックアップ オペレーションが作成されます。

バックアップの外部整合性を確保するために、Cloud Spanner によって、作成時にデータベースのコンテンツが固定されます。これにより、バックアップ オペレーションの実行中は、ガベージ コレクション システムによって関連するデータ値が削除されることが回避されます。その後、インスタンス内のすべてのゾーンでデータのコピーが開始されます。ゾーンが一時的に使用不可になっている場合、そのゾーンがオンラインに戻って完了するまでバックアップは完了しません。オペレーションが完了したら、すぐにバックアップを復元できます。

リソース階層

バックアップは Cloud Spanner のリソースです。各バックアップ リソースは、リソース階層内のソース データベースと同じインスタンスごとにまとめられ、リソースパスは projects/<project>/instances/<instance>/backups/<backup> 形式になります。ソース データベースが削除された後もバックアップは存在し続けますが、親インスタンスより長く存続することはできません。バックアップがある場合は、バックアップが誤って削除されないようにするために、Cloud Spanner インスタンスを削除できません。インスタンスを削除する場合は、バックアップを復元し、復元したデータベースをエクスポートしてから、バックアップとインスタンスを削除することをおすすめします。

バックアップの時間とパフォーマンス

バックアップの作成にかかる時間はさまざまな要因によって異なりますが、主にデータベースのサイズノードの数によって決まります。バックアップにかかる時間を短縮する必要がある場合は、ノード数を増やすことによって実現できますが、ノード数の変更はその後のバックアップに反映されることを念頭に置いてください。

バックアップの作成にはアイドル状態の CPU も使用するため、CPU 使用率が推奨ガイドラインの範囲内であることを確認してください。CPU が過負荷になると、バックアップにかかる時間が非常に長くなり、データベースのレイテンシに悪影響を与える可能性があります。

インスタンス内の CPU は、インスタンス内のすべての進行中のバックアップで共有されます。同じインスタンスで複数のデータベースのバックアップを同時に作成すると、バックアップにかかる時間が長くなる可能性があります。

復元の仕組み

復元時に、ソース バックアップと新しいターゲット データベースを指定する必要があります。既存のデータベースに復元することはできません。新しいデータベースがバックアップと同じプロジェクトに存在し、バックアップと同じインスタンス構成でインスタンスに存在している必要があります。たとえば、us-west3 が構成されたインスタンスにバックアップが存在している場合、us-west3 も構成されているプロジェクト内の任意のインスタンスに復元できます。インスタンスのノード数を同じにする必要はありません。復元されたデータベースには、バックアップの create_time にある元のデータベースのすべてのデータとスキーマが含まれます。復元されたデータベースが含まれているインスタンスから継承されたものを除き、IAM 権限はありません。復元が完了したら、適切な IAM 権限を適用する必要があります。データベースでインスタンスのリージョンとゾーンの大部分のクォーラムが使用可能である限り、復元プロセスは高可用性を実現するように設計されます。

復元されたデータベースの 3 つの States 間での移行は、2 つのオペレーションによってトラッキングされることを理解しておく必要があります。

  • CREATING 状態: 復元を開始すると、新しいデータベースと長時間実行データベース オペレーションRestoreDatabaseMetadata を使用して作成され、復元の進捗状況がトラッキングされます。新しいデータベースが開始され、CREATING 状態のままになります。つまり、復元オペレーションが完了するまで使用できません。復元時間を短縮するために(通常は 10 分以内)、復元オペレーションでは、バックアップ内のファイルをデータベースにコピーせずにマウントします。

  • READY_OPTIMIZING 状態: 復元オペレーションが完了すると、データベースが READY_OPTIMIZING 状態に移行します。この状態では、データベースは使用可能ですが、データベースでバックアップからデータを読み取る際に、若干の読み取りレイテンシが発生する可能性があります。データベースの復元や最適化に使用されている間にバックアップを削除しようとすると、失敗します。

    復元オペレーションが完了すると、OptimizeRestoredDatabaseMetadata での別の長時間実行データベース オペレーションが発生し、最適化の進捗状況がトラッキングされます。最適化オペレーションで、バックアップからデータベースにデータがコピーされます。最適化プロセスにかかる時間を短縮するには、インスタンスにノードを追加します。

  • READY 状態: 最適化オペレーションが完了すると、データベースが 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 をご覧ください。