Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Récupération des données DLT après suppression de la pile

Cette section décrit comment restaurer des scénarios de test et exécuter l'historique dans une nouvelle pile DLT après la suppression de la pile d'origine. Cela s'applique lorsque les compartiments S3 et les tables DynamoDB du client ont été conservés (comportement par défaut) et que le client souhaite les reconnecter à un nouveau déploiement.

Contexte

Lorsqu'une pile DLT est supprimée, les ressources suivantes sont conservées dans le compte AWS du client conformément aux politiques de protection des données :

Tous les noms de ressources sont générés automatiquement par CloudFormation. Ils ne sont pas prévisibles et ne peuvent pas être spécifiés en tant que paramètres lors du déploiement d'une nouvelle pile.

Contraintes importantes

Processus de rétablissement

Étape 1 : Identifier les ressources conservées

Avant de déployer une nouvelle pile, localisez les ressources conservées dans la pile supprimée.

# 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 vous avez noté les sorties de la CloudFormation pile avant la suppression, utilisez ces noms exacts. Les résultats pertinents étaient les suivants :

Pour les ressources qui ne sont pas exposées sous forme de sorties de pile (telles que la table d'historique), list-stack-resources utilisez-la avant la suppression pour obtenir les identifiants des ressources physiques. Cette commande répertorie toutes les ressources de la pile, qu'elles aient ou non une sortie correspondante.

Étape 2 : Déployer une nouvelle pile DLT

Déployez une nouvelle pile DLT en utilisant la même version de CloudFormation modèle (ou une version plus récente). Utilisez les mêmes paramètres que le déploiement d'origine (paramètres VPC, e-mail de l'administrateur, 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

Attendez que la pile atteigne CREATE_COMPLETE son statut.

Étape 3 : Identifier les ressources de la nouvelle pile

Récupérez les noms des ressources à partir des sorties de la nouvelle pile.

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

Notez les valeurs pour :

Pour toute ressource non exposée sous forme de sortie de pile (telle que la table d'historique), utilisez cette list-stack-resources option pour la rechercher par son identifiant logique :

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

Cette commande répertorie toutes les ressources gérées par la pile. Vous pouvez filtrer par sous-chaîne d'ID logique pour trouver n'importe quelle ressource.

Étape 4 : migrer les données DynamoDB

Exportez les données des tables conservées et importez-les dans les nouvelles tables. Utilisez l'exportation de données DynamoDB ou les opérations de numérisation et d'écriture.

Option A : utilisation de Export/Import DynamoDB (recommandée pour les grands ensembles de données)

Pour les tables contenant des milliers d'éléments, utilisez une exportation DynamoDB vers S3 suivie d'une importation :

# 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

Option B : Numériser et BatchWrite (recommandé)

Cette approche permet de lire directement les tables conservées et d'écrire dans les tables de la nouvelle pile sans provoquer de dérive de la pile. Il nécessite Python 3 et la boto3 bibliothèque.

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

Pour les tables de grande taille (des dizaines de milliers d'éléments), pensez à utiliser des segments de numérisation parallèles pour accélérer la phase de lecture.

Option C : Restaurer à partir du PITR (dans un délai de 35 jours)

Si la pile a été supprimée au cours des 35 derniers jours et que le PITR a été activé (c'est le cas par défaut), vous pouvez restaurer la table à un moment donné. Cependant, les restaurations PITR créent une nouvelle table portant un nom différent. Vous devez donc toujours copier les données dans la table gérée par pile à l'aide de l'option 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

Étape 5 : migrer les données S3

Copiez les scripts de test et les fichiers de résultats du bucket conservé vers le bucket de la nouvelle pile.

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

Cela copie :

Étape 6 : vérifier la migration

Étape 7 : Nettoyer les ressources conservées

Après avoir vérifié que toutes les données ont bien été migrées, supprimez les anciennes ressources conservées afin d'éviter des coûts de stockage permanents.

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

N'effectuez cette étape qu'après avoir confirmé que la nouvelle pile est pleinement opérationnelle et que toutes les données historiques sont intactes.

Éviter la dérive des piles

La dérive de la pile se produit lorsque l'état réel d'une ressource diffère de ce qui CloudFormation était attendu. Pour éviter toute dérive au cours de ce processus de restauration :

L'écriture de données dans CloudFormation-managed des tables et des compartiments est sûre car elle CloudFormation permet de suivre la configuration des ressources (schéma de table, mode de facturation, paramètres de chiffrement), et non le contenu des données.

Ce qui ne peut pas être récupéré

Les éléments suivants sont perdus lorsqu'une pile est supprimée et ne peuvent pas être restaurés par le biais de ce processus :

Mesures préventives

Pour simplifier les futurs scénarios de restauration, procédez comme suit :