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: | Recurso | Contém | Nomenclatura | | --- | --- | --- | | Cenários: bucket S3 | Scripts de teste (JMeter/K6/Locust), arquivos XML de resultados por tarefa, ativos da estrutura JMeter | Auto-generated (por exemplo,`dltstack-scenariosbucket-abc123`) | | Registra o bucket S3 | Registros de acesso do S3 para todos os buckets DLT | Auto-generated | | Console S3, balde | Ativos estáticos da interface da Web | Auto-generated | | Tabela de cenários do DynamoDB | Definições de teste, configurações e regras de agendamento | Auto-generated (por exemplo,`DLTStack-ScenariosTable-xyz789`) | | Tabela de histórico do DynamoDB | Resultados, durações e taxas de sucesso dos testes | Auto-generated (por exemplo,`DLTStack-HistoryTable-xyz789`) | | CloudWatch grupos de registros | Registros de execução do Lambda e do ECS (retenção de 10 anos) | Nomeado por função | 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 1. O CloudFormation modelo DLT não aceita parâmetros para tabelas ou buckets do S3 existentes do DynamoDB. Uma nova implantação sempre cria novos recursos. 1. A modificação direta de CloudFormation-managed recursos fora da pilha causa o desvio da pilha. Toda migração de dados deve ocorrer no nível dos dados, não no nível da infraestrutura. 1. O UUID da solução é gerado aleatoriamente em cada nova implantação. A nova pilha terá um UUID diferente do original. 1. As tabelas do DynamoDB Point-in-Time têm a Recuperação (PITR) ativada por padrão, fornecendo backups contínuos nos últimos 35 dias. ## 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: + `ScenariosBucket`— o nome do bucket S3 + `ScenariosTable`— o nome da tabela de cenários do DynamoDB 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= \ ParameterKey=AdminEmail,ParameterValue= \ --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: + `ScenariosBucket`(novo nome do bucket) + `ScenariosTable`(novo nome da tabela) 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:::table/ \ --s3-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=,S3KeyPrefix=dlt-migration/scenarios/ \ --table-creation-parameters '{"TableName":"","KeySchema":[{"AttributeName":"testId","KeyType":"HASH"}],"AttributeDefinitions":[{"AttributeName":"testId","AttributeType":"S"}],"BillingMode":"PAY_PER_REQUEST"}' \ --input-format DYNAMODB_JSON ``` **nota** A `import-table` API cria uma nova tabela. Como a nova pilha já criou a tabela de destino, use a Opção B em vez disso, ou exclua primeiro a nova tabela vazia e recrie-a por meio da importação (isso causará desvio da pilha, veja o aviso abaixo). **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="") 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("", "") # Migrate history migrate_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 \ --target-table-name dlt-scenarios-restored \ --restore-date-time # 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:// \ s3:// \ --source-region \ --region ``` Isso copia: + Scripts de teste (`.jmx`arquivos JMeter, scripts K6, arquivos Locust, arquivos ZIP) + Arquivos XML do resultado do teste organizados por ID e região do teste + Ativos e plug-ins da estrutura JMeter ### Etapa 6: Verificar a migração 1. Faça login no console web do DLT usando o URL da nova pilha (encontrado na saída da `WebConsole` pilha). 1. Confirme se todos os cenários de teste aparecem na lista de cenários. 1. Abra cenários individuais e verifique se o histórico da execução do teste está visível. 1. Confirme se os scripts de teste podem ser baixados na página de detalhes do cenário. 1. Faça um pequeno teste para verificar a funcionalidade de ponta a ponta com a nova pilha. ### 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 aws dynamodb delete-table --table-name # Empty and delete old S3 buckets aws s3 rm s3:// --recursive aws s3api delete-bucket --bucket aws s3 rm s3:// --recursive aws s3api delete-bucket --bucket aws s3 rm s3:// --recursive aws s3api delete-bucket --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: + NÃO renomeie nem modifique diretamente as tabelas do DynamoDB ou os buckets do S3 da nova pilha. + NÃO use `import-table` para substituir as tabelas da nova pilha (isso exigiria a exclusão da CloudFormation-managed tabela primeiro). + NÃO modifique políticas do IAM, políticas de bucket ou configurações de tabela fora do CloudFormation. + USE somente operações em nível de dados:`PutItem`,,`BatchWriteItem`,`s3 sync`. `s3 cp` + GRAVE dados nas tabelas e nos buckets CloudFormation criados. Adicionar itens a uma tabela do DynamoDB ou objetos a um bucket do S3 não constitui desvio. 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: | Item | Motivo | | --- | --- | | Contas de usuário do Cognito | O grupo de usuários é excluído com a pilha. Os usuários devem se registrar novamente. | | EventBridge Horários ativos | As regras de teste agendadas são excluídas. Recrie agendas manualmente na interface do usuário do DLT. | | CloudWatch painéis | Per-test os painéis (`EcsLoadTesting*`) são excluídos. Novas execuções criarão novos painéis. | | Solução UUID | Um novo UUID aleatório é gerado. Isso afeta somente a correlação de métricas operacionais. | | Associações regionais de pilhas | As pilhas regionais devem ser reimplantadas e reassociadas à nova pilha de hubs. | ## Medidas preventivas Para simplificar os cenários futuros de recuperação: 1. Grave as saídas da pilha antes de qualquer exclusão. Salve os nomes `ScenariosBucket``ScenariosTable`, e da tabela de histórico. 1. Ative a PITR do DynamoDB (ativada por padrão no DLT). Verifique se ele permanece ativo. 1. Ative o controle de versão do S3 (ativado por padrão no bucket de cenários). Isso protege contra a exclusão acidental de objetos. 1. Considere ativar a proteção contra exclusão do DynamoDB nos cenários e nas tabelas de histórico como uma proteção adicional: ``` aws dynamodb update-table \ --table-name \ --deletion-protection-enabled ``` 1. Use o AWS Backup para criar backups programados de tabelas do DynamoDB para retenção de longo prazo além da janela PITR de 35 dias.