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:
| Recurso | Contiene | Nomenclatura |
| --- | --- | --- |
| Escenarios: depósito de S3 | Scripts de prueba (JMeter/K6/Locust), archivos XML de resultados por tarea, activos del marco JMeter | Auto-generated (por ejemplo,) `dltstack-scenariosbucket-abc123` |
| Registra un bucket S3 | Registros de acceso a S3 para todos los depósitos de DLT | Auto-generated |
| Cubeta S3 de consola | Recursos estáticos de la interfaz de usuario web | Auto-generated |
| Tabla de escenarios de DynamoDB | Pruebe las definiciones, las configuraciones y las reglas de programación | Auto-generated (por ejemplo,`DLTStack-ScenariosTable-xyz789`) |
| Tabla Historial de DynamoDB | Resultados, duraciones y tasas de éxito de las pruebas | Auto-generated (por ejemplo,`DLTStack-HistoryTable-xyz789`) |
| CloudWatch grupos de registros | Registros de ejecución de Lambda y ECS (10 años de retención) | Nombrado por función |
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
1. La CloudFormation plantilla DLT no acepta parámetros para las tablas de DynamoDB o los buckets S3 existentes. Una implementación nueva siempre crea nuevos recursos.
1. La modificación directa de CloudFormation-managed los recursos que están fuera de la pila provoca que la pila se desvíe. Toda la migración de datos debe realizarse a nivel de datos, no a nivel de infraestructura.
1. El UUID de la solución se genera aleatoriamente en cada nueva implementación. La nueva pila tendrá un UUID diferente al original.
1. Las tablas de DynamoDB Point-in-Time tienen habilitada la recuperación (PITR) de forma predeterminada, lo que proporciona copias de seguridad continuas durante los últimos 35 días.
## 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:
+ `ScenariosBucket`— el nombre del bucket S3
+ `ScenariosTable`— el nombre de la tabla de escenarios de DynamoDB
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= \
ParameterKey=AdminEmail,ParameterValue= \
--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:
+ `ScenariosBucket`(nombre del nuevo depósito)
+ `ScenariosTable`(nombre de tabla nuevo)
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:::table/ \
--s3-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=,S3KeyPrefix=dlt-migration/scenarios/ \
--table-creation-parameters '{"TableName":"","KeySchema":[{"AttributeName":"testId","KeyType":"HASH"}],"AttributeDefinitions":[{"AttributeName":"testId","AttributeType":"S"}],"BillingMode":"PAY_PER_REQUEST"}' \
--input-format DYNAMODB_JSON
```
**nota**
La `import-table` API crea una tabla nueva. Como la nueva pila ya creó la tabla de destino, utilice la opción B en su lugar o elimine primero la nueva tabla vacía y vuelva a crearla mediante la importación (esto provocará que la pila se desvíe, consulte la siguiente advertencia).
**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="")
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("", "")
# Migrate history
migrate_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 \
--target-table-name dlt-scenarios-restored \
--restore-date-time
# 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:// \
s3:// \
--source-region \
--region
```
Esto copia:
+ Guiones de prueba (`.jmx`archivos JMeter, scripts K6, archivos Locust, archivos ZIP)
+ Archivos XML de resultados de pruebas organizados por ID de prueba y región
+ Activos y complementos del marco JMeter
### Paso 6: Verificar la migración
1. Inicie sesión en la consola web de DLT con la URL de la nueva pila (que se encuentra en el resultado de la `WebConsole` pila).
1. Confirme que todos los escenarios de prueba aparecen en la lista de escenarios.
1. Abra escenarios individuales y compruebe que el historial de ejecución de las pruebas esté visible.
1. Confirme que los scripts de prueba se pueden descargar desde la página de detalles del escenario.
1. Realice una pequeña prueba para verificar la funcionalidad integral con la nueva pila.
### 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
aws dynamodb delete-table --table-name
# Empty and delete old S3 buckets
aws s3 rm s3:// --recursive
aws s3api delete-bucket --bucket
aws s3 rm s3:// --recursive
aws s3api delete-bucket --bucket
aws s3 rm s3:// --recursive
aws s3api delete-bucket --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:
+ NO cambie el nombre ni modifique directamente las tablas de DynamoDB o los depósitos S3 de la nueva pila.
+ NO las utilices `import-table` para reemplazar las tablas de la nueva pila (esto requeriría eliminar primero la CloudFormation-managed tabla).
+ NO modifique las políticas de IAM, las políticas de grupos ni la configuración de las tablas fuera de CloudFormation ellas.
+ Utilice únicamente operaciones a nivel de datos:`PutItem`,,`BatchWriteItem`,`s3 sync`. `s3 cp`
+ ESCRIBA los datos en las tablas y los cubos que CloudFormation los creó. Añadir elementos a una tabla de DynamoDB u objetos a un bucket de S3 no constituye una desviació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:
| Elemento | Motivo |
| --- | --- |
| Cuentas de usuario de Cognito | El grupo de usuarios se elimina con la pila. Los usuarios deben volver a registrarse. |
| Horarios activos EventBridge | Se eliminan las reglas de las pruebas programadas. Vuelva a crear los horarios manualmente en la interfaz de usuario de DLT. |
| CloudWatch paneles | Per-test se eliminan los paneles (`EcsLoadTesting*`). Las nuevas ejecuciones crearán nuevos paneles. |
| UUID de la solución | Se genera un nuevo UUID aleatorio. Esto afecta únicamente a la correlación de las métricas operativas. |
| Asociaciones de pilas regionales | Las pilas regionales deben redistribuirse y volver a asociarse a la nueva pila central. |
## Medidas preventivas
Para simplificar los escenarios de recuperación futuros:
1. Registre los resultados de la pila antes de eliminarlos. Guarde los nombres de las tablas `ScenariosBucket``ScenariosTable`, y del historial.
1. Habilite el PITR de DynamoDB (activado de forma predeterminada en DLT). Compruebe que permanezca activo.
1. Habilite el control de versiones en S3 (activado de forma predeterminada en el bucket de escenarios). Esto protege contra la eliminación accidental de objetos.
1. Considere habilitar la protección de eliminación de DynamoDB en los escenarios y las tablas de historial como medida de seguridad adicional:
```
aws dynamodb update-table \
--table-name \
--deletion-protection-enabled
```
1. Utilice AWS Backup para crear copias de seguridad programadas de las tablas de DynamoDB para su retención a largo plazo más allá del período PITR de 35 días.