このページでは、ポイントインタイム リカバリ(PITR)を使用して Spanner のデータ保持、データ復元の方法について説明します。
詳細については、ポイントインタイム リカバリをご覧ください。
前提条件
このガイドでは、Spanner クイックスタートで定義されているデータベースとスキーマを使用します。クイックスタートでデータベースとスキーマを作成するか、独自のデータベースで使用するようにコマンドを変更します。
保持期間の設定
データベースの保持期間を設定するには:
Console
Google Cloud コンソールで、[Spanner インスタンス] ページに移動します。
データベースが含まれているインスタンスをクリックして、[概要] ページを開きます。
データベースをクリックして [概要] ページを開きます。
[バックアップ/復元] タブを選択します。
[バージョン保持期間] フィールドの鉛筆アイコンをクリックします。
保持期間の数量と時間の単位を入力し、[更新] をクリックします。
gcloud
ALTER DATABASE ステートメントでデータベースのスキーマを更新します。次に例を示します。
gcloud spanner databases ddl update example-db --instance=test-instance \
--ddl='ALTER DATABASE `example-db` SET OPTIONS (version_retention_period="7d");'
保持期間を表示するには、データベースの DDL を取得します。
gcloud spanner databases ddl describe example-db --instance=test-instance
出力は次のとおりです。
ALTER DATABASE example-db SET OPTIONS (
version_retention_period = '7d'
);
...
クライアント ライブラリ
C#
C++
Go
Java
Node.js
PHP
Python
Ruby
使用上の注意:
- 保持期間は 1 時間から 7 日の間で指定できます。日数、時間、分、秒で指定します。たとえば、
1d
、24h
、1440m
、86400s
の値は同義です。 - プロジェクトで Spanner API のロギングを有効化している場合、イベントは UpdateDatabaseDdl として記録され、ログ エクスプローラに表示されます。
- 保持期間をデフォルトの 1 時間に戻すには、
version_retention_period
データベース オプションをNULL
(GoogleSQL データベースの場合)またはDEFAULT
(PostgreSQL データベースの場合)に設定します。 - 保持期間を延長しても、システムによって以前のバージョンのデータがバックフィルされることはありません。たとえば、保持期間を 1 時間から 24 時間に延長した場合、過去 24 時間のデータを復元するには、システムによる古いデータの蓄積を 23 時間待つ必要があります。
保持期間と最短版の時間を取得する
Database リソースには次の 2 つのフィールドがあります。
version_retention_period
: Spanner がデータベースのすべてのバージョンのデータを保持する期間。earliest_version_time
: 古いバージョンのデータをデータベースから読み取ることができる最も古いタイムスタンプ。この値は Spanner によって継続的に更新されますが、クエリが行われるとその時点で最新ではなくなります。この値を使用してデータを復元する場合、値がクエリされてから復元を行うまでの間に経過した時間を考慮する必要があります。
Console
Google Cloud コンソールで、[Spanner インスタンス] ページに移動します。
データベースが含まれているインスタンスをクリックして、[概要] ページを開きます。
データベースをクリックして [概要] ページを開きます。
[バックアップ/復元] タブを選択して [バックアップ/復元] ページを開き、保持期間を表示します。
[作成] をクリックして [バックアップを作成] ページを開き、最も早いバージョン時間を表示します。
gcloud
これらのフィールドを取得するには、describe databases または list databases を呼び出します。 次に例を示します。
gcloud spanner databases describe example-db --instance=test-instance
出力は次のとおりです。
createTime: '2020-09-07T16:56:08.285140Z'
earliestVersionTime: '2020-10-07T16:56:08.285140Z'
name: projects/my-project/instances/test-instance/databases/example-db
state: READY
versionRetentionPeriod: 3d
データベースの一部を復元する
ステイル読み取りを実行し、目的のリカバリタイムスタンプを指定します。データベースの
earliest_version_time.
より後のタイムスタンプを指定するようにしてください。gcloud
execute-sql を使用します。例:
gcloud spanner databases execute-sql example-db --instance=test-instance --read-timestamp=2020-09-11T10:19:36.010459-07:00 --sql='SELECT * FROM SINGERS'
クライアント ライブラリ
ステイル読み取りの実行をご覧ください。
クエリの結果を保存します。これは、同じトランザクションでクエリの結果をデータベースに書き込むことができないためです。データの量が少ない場合は、コンソールに出力するか、メモリ内に保存します。大量のデータの場合は、ローカル ファイルへの書き込みが必要になることがあります。
復元したデータを、復元が必要なテーブルに書き戻します。例:
gcloud
gcloud spanner rows update --instance=test-instance --database=example-db --table=Singers --data=SingerId=1,FirstName='Marc'
詳細については、gcloud を使用したデータの更新をご覧ください。
クライアント ライブラリ
DML を使用したデータの更新またはミューテーションを使用したデータの更新をご覧ください。
必要に応じて、書き戻す前に復元されたデータを分析する場合は、同じデータベースに一時テーブルを手動で作成し、復元したデータをこの一時テーブルに書き込み、分析を行ってから、一時的なテーブルから復元するデータを読み取り、復元が必要なテーブルに書き込みます。
データベース全体を復元する
バックアップと復元またはインポートとエクスポートを使用し、リカバリ タイムスタンプを指定することで、データベース全体をバックアップできます。
バックアップと復元
バックアップを作成し、
version_time
を目的のリカバリ タイムスタンプに設定します。Console
Cloud Console で [データベースの詳細] ページに移動します。
[バックアップ / 復元] タブで、[作成] をクリックします。
[create backup from an earlier point in time] チェックボックスをオンにします。
gcloud
gcloud spanner backups create example-db-backup-1 --instance=test-instance \ --database=example-db --retention-period=1y --version-time=2021-01-22T01:10:35Z --async
詳細については、gcloud を使用してバックアップを作成するをご覧ください。
クライアント ライブラリ
C#
C++
Go
Java
Node.js
PHP
Python
Ruby
バックアップから新しいデータベースに復元します。Spanner は、バックアップから復元されたデータベースまでの保持期間の設定を保持します。
Console
Cloud Console の [インスタンスの詳細] ページに移動します。
[バックアップ / 復元] タブで、バックアップを選択して [復元] をクリックします。
gcloud
gcloud spanner databases restore --async \ --destination-instance=destination-instance --destination-database=example-db-restored \ --source-instance=test-instance --source-backup=example-db-backup-1
詳細については、バックアップからのデータベースの復元をご覧ください。
クライアント ライブラリ
C#
C++
Go
Java
Node.js
PHP
Python
Ruby
インポートとエクスポート
snapshotTime
パラメータを目的のリカバリ タイムスタンプに指定して、データベースをエクスポートします。Console
Cloud Console の [インスタンスの詳細] ページに移動します。
[インポート / エクスポート] タブで [エクスポート] をクリックします。
[Export database from an earlier point in time] チェックボックスをオンにします。
詳細な手順については、データベースのエクスポートをご覧ください。
gcloud
[Spanner] to Avro](/dataflow/docs/guides/templates/provided-batch#cloud_spanner_to_gcs_avro) Dataflow テンプレートを使用して、データベースをエクスポートします。
gcloud dataflow jobs run JOB_NAME \ --gcs-location='gs://cloud-spanner-point-in-time-recovery/Import Export Template/export/templates/Cloud_Spanner_to_GCS_Avro' --region=DATAFLOW_REGION --parameters='instanceId=test-instance,databaseId=example-db,outputDir=YOUR_GCS_DIRECTORY,snapshotTime=2020-09-01T23:59:40.125245Z'
使用上の注意:
- Dataflow コンソール でインポート ジョブとエクスポート ジョブの進行状況を追跡できます。
- Spanner は、エクスポートされるデータが指定したタイムスタンプの時点で外部の観点からもトランザクションの観点からも一貫性があることを保証します。
- RFC 3339 形式でタイムスタンプを指定します。例: 2020-09-01T23:59:30.234233Z
- データベースの
earliest_version_time
より後のタイムスタンプを指定するようにしてください。指定したタイムスタンプにデータが存在しない場合は、エラーが発生します。
新しいデータベースにインポートします。
Console
Cloud Console の [インスタンスの詳細] ページに移動します。
[インポート / エクスポート] タブで [インポート] をクリックします。
詳細な手順については、Spanner に Avro ファイルをインポートするをご覧ください。
gcloud
[Cloud Storage] Avro to Spanner](/dataflow/docs/guides/templates/provided-batch#gcs_avro_to_cloud_spanner) Dataflow テンプレートを使用して、Avro ファイルをインポートします。
gcloud dataflow jobs run JOB_NAME \ --gcs-location='gs://cloud-spanner-point-in-time-recovery/Import Export Template/import/templates/GCS_Avro_to_Cloud_Spanner' \ --region=DATAFLOW_REGION \ --staging-location=YOUR_GCS_STAGING_LOCATION \ --parameters='instanceId=test-instance,databaseId=example-db,inputDir=YOUR_GCS_DIRECTORY'
ストレージの増加を見積もる
データベースのバージョン保持期間を延長する前に、希望する期間のトランザクション バイト数を合計することで、データベース ストレージの使用率の増加予測を見積もることができます。たとえば、次のクエリは、トランザクションの統計情報テーブルから読み取り、過去 7 日間(168 時間)に書き込まれた GiB の数を計算します。
GoogleSQL
SELECT
SUM(bytes_per_hour) / (1024 * 1024 * 1024 ) as GiB
FROM (
SELECT
((commit_attempt_count - commit_failed_precondition_count - commit_abort_count) * avg_bytes) AS bytes_per_hour,
interval_end
FROM
spanner_sys.txn_stats_total_hour
ORDER BY
interval_end DESC
LIMIT
168);
PostgreSQL
SELECT
bph / (1024 * 1024 * 1024 ) as GiB
FROM (
SELECT
SUM(bytes_per_hour) as bph
FROM (
SELECT
((commit_attempt_count - commit_failed_precondition_count - commit_abort_count) * avg_bytes) AS bytes_per_hour,
interval_end
FROM
spanner_sys.txn_stats_total_hour
ORDER BY
interval_end DESC
LIMIT
168)
sub1) sub2;
クエリ結果はおおよその見積もりであり、いくつかの理由により不正確になる可能性があることにご注意ください。
- このクエリは、古いデータの各バージョンごとに保存する必要がある タイムスタンプ を考慮しません。データベースが数多くの小規模なデータ型で構成されている場合、ストレージ増量が少なめに見積もられる場合があります。
- クエリにはすべての書き込みオペレーションを網羅しますが、古いバージョンのデータを作成するのは更新オペレーションだけです。ワークロードに挿入オペレーションが多数含まれている場合、クエリはストレージ増量が多めに見積もられる場合があります。