As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Recuperando dados DLT após a exclusão da pilha

Esta seção descreve como restaurar cenários de teste e executar o histórico em uma nova pilha DLT após a exclusão da pilha original. Ela se aplica quando os buckets do S3 e as tabelas do DynamoDB do cliente são mantidos (o comportamento padrão) e o cliente quer reconectá-los a uma nova implantação.

Contexto

Quando uma pilha de DLT é excluída, os seguintes recursos são retidos na conta da AWS do cliente devido às políticas de proteção de dados:

Todos os nomes de recursos são gerados automaticamente por CloudFormation. Eles não são previsíveis e não podem ser especificados como parâmetros ao implantar uma nova pilha.

Restrições importantes

Processo de recuperação

Etapa 1: Identificar os recursos retidos

Antes de implantar uma nova pilha, localize os recursos retidos da pilha excluída.

# 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 você anotou as saídas da CloudFormation pilha antes da exclusão, use esses nomes exatos. Os resultados relevantes foram:

Para recursos não expostos como saídas de pilha (como a tabela de histórico), use list-stack-resources antes da exclusão para obter as IDs dos recursos físicos. Esse comando lista todos os recursos na pilha, independentemente de terem uma saída correspondente.

Etapa 2: implantar uma nova pilha DLT

Implante uma nova pilha de DLT usando a mesma versão do CloudFormation modelo (ou mais recente). Use os mesmos parâmetros da implantação original (configurações de VPC, e-mail do 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=<admin-name> \
               ParameterKey=AdminEmail,ParameterValue=<admin-email> \
  --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND

Aguarde até que a pilha alcance o CREATE_COMPLETE status.

Etapa 3: identificar os recursos da nova pilha

Recupere os nomes dos recursos das saídas da nova pilha.

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

Observe os valores para:

Para qualquer recurso não exposto como uma saída de pilha (como a tabela de histórico), use list-stack-resources para encontrá-lo por seu ID lógico:

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

Esse comando lista todos os recursos gerenciados pela pilha. Você pode filtrar por substring de ID lógica para encontrar qualquer recurso.

Etapa 4: migrar dados do DynamoDB

Exporte dados das tabelas retidas e importe-os para as novas tabelas. Use operações de exportação de dados ou digitalização e gravação do DynamoDB.

Opção A: usar o Export/Import DynamoDB (recomendado para grandes conjuntos de dados)

Para tabelas com milhares de itens, use uma exportação do DynamoDB para o S3 seguida de uma importação:

# 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

Opção B: Digitalizar e BatchWrite (recomendado)

Essa abordagem lê diretamente das tabelas retidas e grava nas tabelas da nova pilha sem causar desvio da pilha. Isso requer o Python 3 e a 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="<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>")

Para tabelas grandes (dezenas de milhares de itens), considere usar segmentos de varredura paralela para acelerar a fase de leitura.

Opção C: Restaurar a partir da PITR (se dentro da janela de 35 dias)

Se a pilha foi excluída nos últimos 35 dias e a PITR foi ativada (por padrão), você poderá restaurar a tabela para um determinado momento. No entanto, as restaurações PITR criam uma nova tabela com um nome diferente, então você ainda precisaria copiar os dados na tabela gerenciada por pilha usando a Opção 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

Etapa 5: migrar dados do S3

Copie scripts de teste e arquivos de resultados do bucket retido para o bucket da nova pilha.

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

Isso copia:

Etapa 6: Verificar a migração

Etapa 7: Limpar os recursos retidos

Depois de verificar se todos os dados foram migrados com êxito, exclua os antigos recursos retidos para evitar custos contínuos de armazenamento.

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

Execute essa etapa somente após confirmar que a nova pilha está totalmente operacional com todos os dados históricos intactos.

Evitando o desvio da pilha

O desvio da pilha ocorre quando o estado real de um recurso é diferente do esperado CloudFormation . Para evitar desvios durante esse processo de recuperação:

Gravar dados em CloudFormation-managed tabelas e buckets é seguro porque CloudFormation rastreia a configuração do recurso (esquema da tabela, modo de cobrança, configurações de criptografia), não o conteúdo dos dados.

O que não pode ser recuperado

O seguinte é perdido quando uma pilha é excluída e não pode ser restaurada por meio desse processo:

Medidas preventivas

Para simplificar os cenários futuros de recuperação: