本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

堆栈删除后恢复 DLT 数据

本节介绍如何在删除原始堆栈后将测试场景和运行历史恢复到新的 DLT 堆栈中。当客户的 S3 存储桶和 DynamoDB 表已保留（默认行为）并且客户希望将它们重新连接到新的部署时，它适用。

背景

删除 DLT 堆栈后，由于数据保护政策，以下资源将保留在客户的 AWS 账户中：

所有资源名称均由自动生成。 CloudFormation它们不可预测，也无法在部署新堆栈时指定为参数。

重要限制

恢复过程

步骤 1：确定保留的资源

在部署新堆栈之前，请从已删除的堆栈中找到保留的资源。

# List retained DynamoDB tables (look for DLT naming patterns)
aws dynamodb list-tables --query "TableNames[?contains(@, 'ScenariosTable') || contains(@, 'HistoryTable')]"

# List retained S3 buckets (look for DLT naming patterns)
aws s3api list-buckets --query "Buckets[?contains(Name, 'dlttestrunnerstoragedlts') || contains(Name, 'dltconsoleresourcesdltda')]"

如果您在删除之前记下了 CloudFormation 堆栈输出，请使用这些确切的名称。相关产出是：

对于未作为堆栈输出公开的资源（例如历史表），list-stack-resources请在删除之前使用来获取物理资源 ID。此命令列出堆栈中的所有资源，无论其是否有相应的输出。

步骤 2：部署新的 DLT 堆栈

使用相同的 CloudFormation 模板版本（或更高版本）部署全新 DLT 堆栈。使用与原始部署相同的参数（VPC 设置、管理员电子邮件等）。

aws cloudformation create-stack \
  --stack-name distributed-load-testing-new \
  --template-url https://s3.amazonaws.com/solutions-reference/distributed-load-testing-on-aws/latest/distributed-load-testing-on-aws.template \
  --parameters ParameterKey=AdminName,ParameterValue=<admin-name> \
               ParameterKey=AdminEmail,ParameterValue=<admin-email> \
  --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND

等待堆栈达到CREATE_COMPLETE状态。

步骤 3：确定新堆栈的资源

从新堆栈的输出中检索资源名称。

aws cloudformation describe-stacks \
  --stack-name distributed-load-testing-new \
  --query "Stacks[0].Outputs"

请注意以下各项的值：

对于任何未作为堆栈输出公开的资源（例如历史表），请使用list-stack-resources其逻辑 ID 进行查找：

aws cloudformation list-stack-resources \
  --stack-name distributed-load-testing-new \
  --query "StackResourceSummaries[?contains(LogicalResourceId, 'HistoryTable')].{LogicalId:LogicalResourceId,PhysicalId:PhysicalResourceId}"

此命令列出了堆栈管理的所有资源。您可以按逻辑 ID 子字符串筛选以查找任何资源。

步骤 4：迁移 DynamoDB 数据

从保留的表中导出数据并将其导入到新表中。使用 DynamoDB 数据导出或扫描和写入操作。

选项 A：使用 Dynamo Export/Import DB（建议用于大型数据集）

对于包含数千个项目的表，使用 DynamoDB 导出到 S3，然后再进行导入：

# Export from retained table to S3
aws dynamodb export-table-to-point-in-time \
  --table-arn arn:aws:dynamodb:<region>:<account>:table/<old-scenarios-table> \
  --s3-bucket <temporary-export-bucket> \
  --s3-prefix dlt-migration/scenarios/ \
  --export-format DYNAMODB_JSON

# Wait for export to complete, then import into new table
aws dynamodb import-table \
  --s3-bucket-source S3Bucket=<temporary-export-bucket>,S3KeyPrefix=dlt-migration/scenarios/ \
  --table-creation-parameters '{"TableName":"<new-scenarios-table>","KeySchema":[{"AttributeName":"testId","KeyType":"HASH"}],"AttributeDefinitions":[{"AttributeName":"testId","AttributeType":"S"}],"BillingMode":"PAY_PER_REQUEST"}' \
  --input-format DYNAMODB_JSON

选项 B：扫描和 BatchWrite （推荐）

这种方法直接从保留的表中读取并写入新堆栈的表，而不会导致堆栈偏移。它需要 Python 3 和boto3库。

# Install boto3 if not already available
pip install boto3

#!/usr/bin/env python3
"""Migrate DynamoDB items directly from retained tables to new stack tables."""

import boto3

dynamodb = boto3.resource("dynamodb", region_name="<region>")

def migrate_table(source_table_name, target_table_name):
    source = dynamodb.Table(source_table_name)
    target = dynamodb.Table(target_table_name)

    # Scan all items from the retained table (handles pagination automatically)
    items = []
    response = source.scan()
    items.extend(response["Items"])
    while "LastEvaluatedKey" in response:
        response = source.scan(ExclusiveStartKey=response["LastEvaluatedKey"])
        items.extend(response["Items"])

    print(f"Scanned {len(items)} items from {source_table_name}")

    # Write items to the new table using batch_writer (handles batching automatically)
    with target.batch_writer() as batch:
        for item in items:
            batch.put_item(Item=item)

    print(f"Wrote {len(items)} items to {target_table_name}")

# Migrate scenarios
migrate_table("<old-scenarios-table>", "<new-scenarios-table>")

# Migrate history
migrate_table("<old-history-table>", "<new-history-table>")

对于大型表（成千上万个项目），可以考虑使用并行扫描段来加快读取阶段。

选项 C：从 PITR 恢复（如果在 35 天的时间范围内）

如果在过去 35 天内删除了堆栈，并且启用了 PITR（默认情况下），则可以将表恢复到某个时间点。但是，PITR 还原会创建一个名称不同的新表，因此您仍然需要使用选项 B 将数据复制到堆栈管理的表中。

# Restore to a new temporary table
aws dynamodb restore-table-to-point-in-time \
  --source-table-name <old-scenarios-table> \
  --target-table-name dlt-scenarios-restored \
  --restore-date-time <timestamp-before-deletion>

# Then scan from dlt-scenarios-restored and batch-write into the new stack's table

步骤 5：迁移 S3 数据

将测试脚本和结果文件从保留的存储桶复制到新堆栈的存储桶。

# Copy all objects from the old scenarios bucket to the new one
aws s3 sync \
  s3://<old-scenarios-bucket> \
  s3://<new-scenarios-bucket> \
  --source-region <region> \
  --region <region>

这复制了：

步骤 6：验证迁移

步骤 7：清理保留的资源

确认所有数据均已成功迁移后，删除保留的旧资源以避免持续的存储成本。

# Delete old DynamoDB tables
aws dynamodb delete-table --table-name <old-scenarios-table>
aws dynamodb delete-table --table-name <old-history-table>

# Empty and delete old S3 buckets
aws s3 rm s3://<old-scenarios-bucket> --recursive
aws s3api delete-bucket --bucket <old-scenarios-bucket>

aws s3 rm s3://<old-logs-bucket> --recursive
aws s3api delete-bucket --bucket <old-logs-bucket>

aws s3 rm s3://<old-console-bucket> --recursive
aws s3api delete-bucket --bucket <old-console-bucket>

只有在确认新堆栈已完全运行且所有历史数据完好无损后才执行此步骤。

避免堆栈漂移

当资源的实际状态与 CloudFormation 预期的状态不同时，就会发生堆栈偏移。为避免在此恢复过程中出现偏差，请执行以下操作：

将数据写入 CloudFormation-managed 表和存储桶是安全的，因为会 CloudFormation 跟踪资源配置（表架构、计费模式、加密设置），而不是数据内容。

无法恢复的东西

删除堆栈后，以下内容将丢失，且无法通过此过程恢复：

预防措施

要简化 future 恢复方案，请执行以下操作：