Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wiederherstellung von DLT-Daten nach dem Löschen des Stacks

In diesem Abschnitt wird beschrieben, wie Sie Testszenarien wiederherstellen und den Verlauf in einem neuen DLT-Stack ausführen, nachdem der ursprüngliche Stack gelöscht wurde. Dies gilt, wenn die S3-Buckets und DynamoDB-Tabellen des Kunden beibehalten wurden (das Standardverhalten) und der Kunde sie erneut mit einer neuen Bereitstellung verbinden möchte.

Hintergrund

Wenn ein DLT-Stack gelöscht wird, bleiben die folgenden Ressourcen aufgrund von Datenschutzrichtlinien im AWS-Konto des Kunden erhalten:

Alle Ressourcennamen werden automatisch von CloudFormation generiert. Sie sind nicht vorhersehbar und können bei der Bereitstellung eines neuen Stacks nicht als Parameter angegeben werden.

Wichtige Einschränkungen

Wiederherstellungsprozess

Schritt 1: Identifizieren Sie die zurückgehaltenen Ressourcen

Bevor Sie einen neuen Stack bereitstellen, suchen Sie die zurückgehaltenen Ressourcen aus dem gelöschten Stack.

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

Wenn Sie sich die CloudFormation Stack-Ausgaben vor dem Löschen notiert haben, verwenden Sie genau diese Namen. Die relevanten Ausgaben waren:

Verwenden Sie für Ressourcen, die nicht als Stack-Ausgaben verfügbar gemacht werden (z. B. die Verlaufstabelle), list-stack-resources vor dem Löschen, um die physischen Ressourcen-IDs abzurufen. Dieser Befehl listet alle Ressourcen im Stapel auf, unabhängig davon, ob sie eine entsprechende Ausgabe hat.

Schritt 2: Stellen Sie einen neuen DLT-Stack bereit

Stellen Sie einen neuen DLT-Stack mit derselben CloudFormation Vorlagenversion (oder neuer) bereit. Verwenden Sie dieselben Parameter wie bei der ursprünglichen Bereitstellung (VPC-Einstellungen, Administrator-E-Mail usw.).

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

Warten Sie, bis der Stack den CREATE_COMPLETE Status erreicht hat.

Schritt 3: Identifizieren Sie die Ressourcen des neuen Stacks

Rufen Sie die Ressourcennamen aus den Ausgaben des neuen Stacks ab.

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

Notieren Sie sich die Werte für:

Verwenden Sie für jede Ressource, die nicht als Stack-Ausgabe verfügbar gemacht wird (z. B. die Verlaufstabelle), list-stack-resources um sie anhand ihrer logischen ID zu finden:

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

Dieser Befehl listet alle Ressourcen auf, die der Stack verwaltet. Sie können nach einer logischen ID-Teilzeichenfolge filtern, um jede Ressource zu finden.

Schritt 4: DynamoDB-Daten migrieren

Exportieren Sie Daten aus den beibehaltenen Tabellen und importieren Sie sie in die neuen Tabellen. Verwenden Sie DynamoDB-Datenexport- oder Scan- und Schreiboperationen.

Option A: Verwendung von DynamoDB Export/Import (empfohlen für große Datensätze)

Verwenden Sie für Tabellen mit Tausenden von Elementen einen DynamoDB-Export nach S3, gefolgt von einem Import:

# 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: Scannen und BatchWrite (empfohlen)

Dieser Ansatz liest direkt aus den beibehaltenen Tabellen und schreibt in die Tabellen des neuen Stacks, ohne dass es zu einer Stack-Drift kommt. Es erfordert Python 3 und die boto3 Bibliothek.

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

Bei großen Tabellen (Zehntausende von Elementen) sollten Sie parallel Scansegmente verwenden, um die Lesephase zu beschleunigen.

Option C: Aus PITR wiederherstellen (falls innerhalb eines Zeitfensters von 35 Tagen)

Wenn der Stapel innerhalb der letzten 35 Tage gelöscht wurde und PITR aktiviert war (dies ist standardmäßig der Fall), können Sie die Tabelle zu einem bestimmten Zeitpunkt wiederherstellen. Bei PITR-Wiederherstellungen wird jedoch eine neue Tabelle mit einem anderen Namen erstellt, sodass Sie immer noch Daten mit Option B in die vom Stack verwaltete Tabelle kopieren müssten.

# 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

Schritt 5: S3-Daten migrieren

Kopieren Sie Testskripte und Ergebnisdateien aus dem beibehaltenen Bucket in den Bucket des neuen Stacks.

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

Dies kopiert:

Schritt 6: Überprüfen Sie die Migration

Schritt 7: Bereinigen Sie die zurückgehaltenen Ressourcen

Nachdem Sie überprüft haben, ob alle Daten erfolgreich migriert wurden, löschen Sie die alten zurückgehaltenen Ressourcen, um laufende Speicherkosten zu vermeiden.

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

Führen Sie diesen Schritt erst aus, nachdem Sie sich vergewissert haben, dass der neue Stack voll funktionsfähig ist und alle historischen Daten intakt sind.

Vermeidung von Stack-Drift

Stack-Drift tritt auf, wenn der tatsächliche Zustand einer Ressource von den Erwartungen CloudFormation abweicht. Gehen Sie wie folgt vor, um Abweichungen während dieses Wiederherstellungsprozesses zu vermeiden:

Das Schreiben von Daten in CloudFormation-managed Tabellen und Buckets ist sicher, da die Ressourcenkonfiguration (Tabellenschema, Abrechnungsmodus, Verschlüsselungseinstellungen) und nicht der Dateninhalt CloudFormation verfolgt wird.

Was kann nicht wiederhergestellt werden

Folgendes geht verloren, wenn ein Stapel gelöscht wird und kann durch diesen Vorgang nicht wiederhergestellt werden:

Präventive Maßnahmen

Um future Wiederherstellungsszenarien zu vereinfachen: