Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Recuperación de datos de DLT después de eliminar la pila

En esta sección se describe cómo restaurar los escenarios de prueba y ejecutar el historial en una nueva pila de DLT después de eliminar la pila original. Se aplica cuando se conservaron los depósitos de S3 y las tablas de DynamoDB del cliente (el comportamiento predeterminado) y el cliente desea volver a conectarlos a una implementación nueva.

Introducción

Cuando se elimina una pila de DLT, los siguientes recursos se conservan en la cuenta de AWS del cliente debido a las políticas de protección de datos:

Todos los nombres de los recursos se generan automáticamente mediante CloudFormation. No son predecibles y no se pueden especificar como parámetros al implementar una nueva pila.

Restricciones importantes

Proceso de recuperación

Paso 1: Identificar los recursos retenidos

Antes de implementar una pila nueva, localice los recursos retenidos de la pila eliminada.

# 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')]"

Si anotaste los resultados de la CloudFormation pila antes de eliminarlos, usa esos nombres exactos. Los resultados relevantes fueron:

En el caso de los recursos que no estén expuestos como salidas de pila (como la tabla de historial), utilícelos list-stack-resources antes de eliminarlos para obtener los identificadores de los recursos físicos. Este comando muestra todos los recursos de la pila, independientemente de si tienen una salida correspondiente.

Paso 2: Implementa una nueva pila de DLT

Implemente una nueva pila de DLT con la misma versión de CloudFormation plantilla (o una más reciente). Utilice los mismos parámetros que en la implementación original (configuración de VPC, correo electrónico del administrador, etc.).

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

Espere a que la pila alcance el CREATE_COMPLETE estado.

Paso 3: Identifica los recursos de la nueva pila

Recupera los nombres de los recursos de los resultados de la nueva pila.

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

Anote los valores de:

Para cualquier recurso que no esté expuesto como salida de una pila (como la tabla de historial), úsalo list-stack-resources para buscarlo por su identificador lógico:

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

Este comando muestra todos los recursos que administra la pila. Puede filtrar por subcadena de ID lógica para encontrar cualquier recurso.

Paso 4: Migrar los datos de DynamoDB

Exporte los datos de las tablas conservadas e impórtelos a las nuevas tablas. Utilice la exportación de datos de DynamoDB o las operaciones de escaneo y escritura.

Opción A: Uso de Export/Import DynamoDB (recomendado para conjuntos de datos grandes)

Para tablas con miles de elementos, utilice una exportación de DynamoDB a S3 seguida de una importación:

# 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

Opción B: Escanear y BatchWrite (recomendada)

Este enfoque lee directamente las tablas retenidas y las escribe en las tablas de la nueva pila sin provocar que la pila se desvíe. Requiere Python 3 y la boto3 biblioteca.

# 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>")

Para tablas grandes (decenas de miles de elementos), considere la posibilidad de utilizar segmentos de escaneo en paralelo para acelerar la fase de lectura.

Opción C: restaurar desde PITR (si se encuentra dentro de un período de 35 días)

Si la pila se eliminó en los últimos 35 días y la PITR estaba habilitada (de forma predeterminada), puedes restaurar la tabla en un momento dado. Sin embargo, las restauraciones de PITR crean una tabla nueva con un nombre diferente, por lo que aún tendrá que copiar los datos en la tabla gestionada por pilas mediante la opción 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

Paso 5: Migrar los datos de S3

Copie los scripts de prueba y los archivos de resultados del depósito retenido al depósito de la nueva pila.

# 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>

Esto copia:

Paso 6: Verificar la migración

Paso 7: Limpiar los recursos retenidos

Tras comprobar que todos los datos se han migrado correctamente, elimine los antiguos recursos retenidos para evitar costes de almacenamiento continuos.

# 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>

Realice este paso solo después de confirmar que la nueva pila está en pleno funcionamiento con todos los datos históricos intactos.

Evitar la deriva de la pila

La desviación de la pila se produce cuando el estado real de un recurso difiere del CloudFormation esperado. Para evitar desviaciones durante este proceso de recuperación:

Escribir datos en CloudFormation-managed tablas y cubos es seguro porque CloudFormation hace un seguimiento de la configuración de los recursos (esquema de la tabla, modo de facturación, configuración de cifrado) y no del contenido de los datos.

¿Qué no se puede recuperar

Cuando se elimina una pila, se pierde lo siguiente y no se puede restaurar mediante este proceso:

Medidas preventivas

Para simplificar los escenarios de recuperación futuros: