Amazon DynamoDB のテーブルをポイントインタイムリカバリで復元すると、TTL やストリームの設定が引き継がれません。設定し直す項目を教えてください
困っていること
Amazon DynamoDB のテーブルを、ポイントインタイムリカバリ（PITR）で数分前の状態に復元しました。
復元した新しいテーブルには、項目とインデックスはあります。ところが、有効期限（TTL）が無効で、DynamoDB ストリームもオフになっていて、タグも付いていません。
元のテーブルの設定は、復元でそのまま引き継がれると思っていました。復元した後に、自分で設定し直す項目を知りたいです。
どう対応すればいいの？
復元で新しいテーブルに引き継がれるのは、データ、グローバルセカンダリインデックス、ローカルセカンダリインデックス、プロビジョニングされたキャパシティ、暗号化の設定です。TTL、ストリーム、タグ、ポイントインタイムリカバリ、削除保護などは引き継がれません。復元が終わった後に、新しいテーブルへ設定し直してください。
次の対策をご検討ください。コマンドのテーブル名は、復元後のテーブルの名前です。
-
TTL を有効にします。属性の名前は、元のテーブルと同じにします。
aws dynamodb update-time-to-live --table-name session-events-restored \ --time-to-live-specification Enabled=true,AttributeName=expires_at -
ストリームを有効にします。
aws dynamodb update-table --table-name session-events-restored \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
このコマンドの後、テーブルのステータスは UPDATING になります。次の update-table は ACTIVE に戻ってから実行するので、aws dynamodb wait table-exists --table-name session-events-restored で待ちます。ストリームを読む AWS Lambda のイベントソースマッピングなどは、新しいストリームの ARN に向け直してください。
-
削除保護を有効にします。
aws dynamodb update-table --table-name session-events-restored --deletion-protection-enabled -
ポイントインタイムリカバリを有効にします。元のテーブルでリカバリ期間を 35 日から変えていた場合は、
--point-in-time-recovery-specificationにRecoveryPeriodInDaysも指定します。aws dynamodb update-continuous-backups --table-name session-events-restored \ --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true -
タグを付けます。
$ARNは復元後のテーブルの ARN で、describe-tableから取り出します。ARN=$(aws dynamodb describe-table --table-name session-events-restored \ --query Table.TableArn --output text) aws dynamodb tag-resource --resource-arn "$ARN" \ --tags Key=owner,Value=katagata Key=env,Value=dev -
IAM ポリシー、自動スケーリングポリシー、Amazon CloudWatch のアラーム、CloudWatch Contributor Insights も、新しいテーブルに合わせて設定し直します。復元でテーブルの名前と ARN が変わるので、元のテーブルを指定しているものは見直してください。
なお、復元にかかる時間は、テーブルのサイズだけでは決まりません。また、ポイントインタイムリカバリが有効なテーブルを削除すると、システムバックアップが 35 日間残ります（追加のコストはかかりません）。
復元で引き継がれない設定
復元で再作成されるものと、自分で設定し直すものは、次のとおりです。
復元では、復元ポイントのソーステーブルの設定から新しいテーブルに、テーブルデータ、グローバルセカンダリインデックス、ローカルセカンダリインデックス、プロビジョニングされた読み込みおよび書き込みキャパシティ、暗号化設定が再作成されます。復元ではこれらの設定が引き継がれないため、復元が完了したら、自動スケーリングポリシー、AWS Identity and Access Management ポリシー、CloudWatch メトリクスとアラーム、タグ、DynamoDB Streams 設定、有効期限設定、ポイントインタイムリカバリ設定を新しいテーブルに自身で設定する必要があります。
テーブルの復元のページの一覧には、削除保護と Contributor Insights の設定も含まれます。
以下は、復元されたテーブルで手動で設定する必要があります。
- 自動スケーリングポリシー
- AWS Identity and Access Management ポリシー
- Amazon CloudWatch Events のメトリクスとアラーム
- CloudWatch Contributor Insights の設定
- タグ
- ストリーム設定
- 有効期限 (TTL) 設定
- 削除保護設定
- ポイントインタイムリカバリ設定
確認してみた
東京リージョンのオンデマンドのテーブル session-events を使いました。パーティションキーは session_id、ソートキーは event_time で、グローバルセカンダリインデックス by_user があります。TTL（属性 expires_at）、ストリーム（NEW_AND_OLD_IMAGES）、削除保護、ポイントインタイムリカバリを有効にし、タグを 2 つ付けて、項目を 30 件入れました。
次のコマンドで、最新の復元可能な時刻に、session-events-restored という名前で復元しました。
aws dynamodb restore-table-to-point-in-time \
--source-table-name session-events \
--target-table-name session-events-restored \
--use-latest-restorable-time
復元の開始から 5 分 21 秒後に describe-table を実行した時点で、新しいテーブルのステータスは ACTIVE になっていました。
元のテーブルと復元後のテーブルで、describe-table・describe-time-to-live・describe-continuous-backups・list-tags-of-resource の出力と、scan --select COUNT の件数を比べました。画像の出力は、--query で必要な項目だけに絞っています。describe-table の ItemCount はおよそ 6 時間ごとに更新される値なので、画像では 0 のままです。件数は scan --select COUNT で数えました。
| 項目 | 元のテーブル | 復元後のテーブル |
|---|---|---|
| 項目の数 | 30 | 30 |
| グローバルセカンダリインデックス by_user | あり | あり |
| 請求モード | オンデマンド | オンデマンド |
| ストリーム | 有効（NEW_AND_OLD_IMAGES） | 無効 |
| 削除保護 | 有効 | 無効 |
| TTL | 有効（expires_at） | 無効 |
| ポイントインタイムリカバリ | 有効 | 無効 |
| タグ | 2 つ | なし |
コンソールでも、復元後のテーブルのポイントインタイムリカバリはオフでした。
その後、「どう対応すればいいの？」の 1〜5 のコマンドで、復元後のテーブルに TTL・ストリーム・削除保護・ポイントインタイムリカバリ・タグを設定し直しました。どのコマンドもエラーは出ていません。update-time-to-live・update-table・update-continuous-backups の応答には有効にした設定が返り、tag-resource の後の list-tags-of-resource ではタグが 2 つ返りました。
検証の後は、2 つのテーブルの削除保護を無効にしてから削除しました。続けて aws dynamodb list-backups --backup-type SYSTEM を実行すると、session-events$DeletedTableBackup と session-events-restored$DeletedTableBackup が AVAILABLE で表示されました。削除したテーブルのシステムバックアップが残っています。
