Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Recupero dei dati DLT dopo l'eliminazione dello stack

Questa sezione descrive come ripristinare gli scenari di test ed eseguire la cronologia in un nuovo stack DLT dopo l'eliminazione dello stack originale. Si applica quando i bucket S3 e le tabelle DynamoDB del cliente sono stati mantenuti (il comportamento predefinito) e il cliente desidera ricollegarli a una nuova implementazione.

Contesto

Quando uno stack DLT viene eliminato, le seguenti risorse vengono conservate nell'account AWS del cliente a causa delle politiche di protezione dei dati:

Tutti i nomi delle risorse vengono generati automaticamente da CloudFormation. Non sono prevedibili e non possono essere specificati come parametri durante la distribuzione di un nuovo stack.

Vincoli importanti

Processo di ripristino

Fase 1: Identificare le risorse conservate

Prima di distribuire un nuovo stack, individua le risorse conservate dallo stack eliminato.

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

Se hai annotato gli output dello CloudFormation stack prima dell'eliminazione, usa quei nomi esatti. I risultati rilevanti erano:

Per le risorse non esposte come output dello stack (come la tabella della cronologia), utilizzale list-stack-resources prima dell'eliminazione per ottenere gli ID delle risorse fisiche. Questo comando elenca tutte le risorse dello stack indipendentemente dal fatto che abbia un output corrispondente.

Fase 2: Implementazione di un nuovo stack DLT

Implementa un nuovo stack DLT utilizzando la stessa versione del CloudFormation modello (o più recente). Utilizza gli stessi parametri della distribuzione originale (impostazioni VPC, e-mail dell'amministratore, ecc.).

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

Attendi che lo stack CREATE_COMPLETE raggiunga lo stato.

Fase 3: Identifica le risorse del nuovo stack

Recupera i nomi delle risorse dagli output del nuovo stack.

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

Nota i valori per:

Per qualsiasi risorsa non esposta come output dello stack (come la tabella della cronologia), usa list-stack-resources per trovarla in base al suo ID logico:

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

Questo comando elenca tutte le risorse gestite dallo stack. È possibile filtrare in base alla sottostringa dell'ID logico per trovare qualsiasi risorsa.

Fase 4: Migrazione dei dati DynamoDB

Esporta i dati dalle tabelle conservate e importali nelle nuove tabelle. Utilizza le operazioni di esportazione dei dati o di scansione e scrittura in DynamoDB.

Opzione A: utilizzo di Export/Import DynamoDB (consigliato per set di dati di grandi dimensioni)

Per le tabelle con migliaia di elementi, utilizza un'esportazione DynamoDB in S3 seguita da un'importazione:

# 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

Opzione B: scansione e (scelta consigliata) BatchWrite

Questo approccio legge direttamente dalle tabelle conservate e scrive nelle tabelle del nuovo stack senza causare variazioni dello stack. Richiede Python 3 e la boto3 libreria.

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

Per tabelle di grandi dimensioni (decine di migliaia di articoli), prendi in considerazione l'utilizzo di segmenti di scansione parallela per accelerare la fase di lettura.

Opzione C: ripristino da PITR (se entro una finestra di 35 giorni)

Se lo stack è stato eliminato negli ultimi 35 giorni e PITR è stato abilitato (per impostazione predefinita), puoi ripristinare la tabella a un determinato punto nel tempo. Tuttavia, i ripristini PITR creano una nuova tabella con un nome diverso, quindi è comunque necessario copiare i dati nella tabella gestita dallo stack utilizzando l'opzione 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

Fase 5: Migrazione dei dati S3

Copia gli script di test e i file dei risultati dal bucket mantenuto al bucket del nuovo stack.

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

Questo copia:

Fase 6: Verifica della migrazione

Fase 7: Pulisci le risorse conservate

Dopo aver verificato che tutti i dati siano stati migrati correttamente, elimina le vecchie risorse conservate per evitare costi di storage continui.

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

Esegui questo passaggio solo dopo aver verificato che il nuovo stack sia completamente operativo con tutti i dati storici intatti.

Evitare la deriva dello stack

La deriva dello stack si verifica quando lo stato effettivo di una risorsa è diverso da quello previsto. CloudFormation Per evitare la deriva durante questo processo di ripristino:

La scrittura di dati in CloudFormation-managed tabelle e bucket è sicura perché CloudFormation tiene traccia della configurazione delle risorse (schema della tabella, modalità di fatturazione, impostazioni di crittografia), non del contenuto dei dati.

Cosa non può essere recuperato

Quanto segue viene perso quando si elimina uno stack e non può essere ripristinato tramite questo processo:

Misure preventive

Per semplificare gli scenari di ripristino futuri: