Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memulihkan data DLT setelah penghapusan tumpukan

Bagian ini menjelaskan cara mengembalikan skenario pengujian dan menjalankan riwayat ke tumpukan DLT baru setelah tumpukan asli dihapus. Ini berlaku ketika bucket S3 pelanggan dan tabel DynamoDB dipertahankan (perilaku default) dan pelanggan ingin menghubungkannya kembali ke penerapan baru.

Latar Belakang

Saat tumpukan DLT dihapus, sumber daya berikut disimpan di akun AWS pelanggan karena kebijakan perlindungan data:

Semua nama sumber daya dibuat secara otomatis oleh CloudFormation. Mereka tidak dapat diprediksi dan tidak dapat ditentukan sebagai parameter saat menerapkan tumpukan baru.

Kendala penting

Proses pemulihan

Langkah 1: Identifikasi sumber daya yang tertahan

Sebelum menerapkan tumpukan baru, cari sumber daya yang disimpan dari tumpukan yang dihapus.

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

Jika Anda mencatat output CloudFormation tumpukan sebelum penghapusan, gunakan nama persis tersebut. Output yang relevan adalah:

Untuk sumber daya yang tidak diekspos sebagai output tumpukan (seperti tabel riwayat), gunakan list-stack-resources sebelum penghapusan untuk mendapatkan ID sumber daya fisik. Perintah ini mencantumkan setiap sumber daya dalam tumpukan terlepas dari apakah ia memiliki output yang sesuai.

Langkah 2: Menyebarkan tumpukan DLT baru

Terapkan tumpukan DLT baru menggunakan versi CloudFormation template yang sama (atau yang lebih baru). Gunakan parameter yang sama dengan penerapan asli (pengaturan VPC, email admin, dll.).

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

Tunggu tumpukan mencapai CREATE_COMPLETE status.

Langkah 3: Identifikasi sumber daya tumpukan baru

Ambil nama sumber daya dari output tumpukan baru.

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

Perhatikan nilai untuk:

Untuk sumber daya apa pun yang tidak diekspos sebagai output tumpukan (seperti tabel riwayat), gunakan list-stack-resources untuk menemukannya dengan ID logisnya:

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

Perintah ini mencantumkan setiap sumber daya yang dikelola tumpukan. Anda dapat memfilter dengan substring ID logis untuk menemukan sumber daya apa pun.

Langkah 4: Migrasikan data DynamoDB

Ekspor data dari tabel yang dipertahankan dan impor ke tabel baru. Gunakan operasi ekspor data DynamoDB atau pindai dan tulis.

Opsi A: Menggunakan Export/Import DynamoDB (direkomendasikan untuk kumpulan data besar)

Untuk tabel dengan ribuan item, gunakan ekspor DynamoDB ke S3 diikuti dengan impor:

# 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

Opsi B: Pindai dan BatchWrite (disarankan)

Pendekatan ini membaca langsung dari tabel yang dipertahankan dan menulis ke tabel tumpukan baru tanpa menyebabkan penyimpangan tumpukan. Ini membutuhkan Python 3 dan perpustakaan. boto3

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

Untuk tabel besar (puluhan ribu item), pertimbangkan untuk menggunakan segmen pemindaian paralel untuk mempercepat fase baca.

Opsi C: Pulihkan dari PITR (jika dalam jendela 35 hari)

Jika tumpukan dihapus dalam 35 hari terakhir dan PITR diaktifkan (secara default), Anda dapat mengembalikan tabel ke titik waktu. Namun, PITR mengembalikan buat tabel baru dengan nama yang berbeda, jadi Anda masih perlu menyalin data ke tabel yang dikelola tumpukan menggunakan Opsi 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

Langkah 5: Migrasikan data S3

Salin skrip pengujian dan file hasil dari bucket yang disimpan ke bucket tumpukan baru.

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

Salinan ini:

Langkah 6: Verifikasi migrasi

Langkah 7: Bersihkan sumber daya yang tertahan

Setelah memverifikasi bahwa semua data telah berhasil dimigrasi, hapus sumber daya lama yang disimpan untuk menghindari biaya penyimpanan yang berkelanjutan.

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

Hanya lakukan langkah ini setelah mengonfirmasi tumpukan baru beroperasi penuh dengan semua data historis utuh.

Menghindari tumpukan drift

Stack drift terjadi ketika keadaan sebenarnya dari sumber daya berbeda dari apa yang CloudFormation diharapkan. Untuk menghindari penyimpangan selama proses pemulihan ini:

Menulis data ke dalam CloudFormation-managed tabel dan bucket aman karena CloudFormation melacak konfigurasi sumber daya (skema tabel, mode penagihan, pengaturan enkripsi), bukan konten data.

Apa yang tidak bisa dipulihkan

Berikut ini hilang ketika tumpukan dihapus dan tidak dapat dipulihkan melalui proses ini:

Tindakan pencegahan

Untuk menyederhanakan skenario pemulihan masa depan: