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á.
# Formato de tabela única para KCL
**A partir do KCL 3.5, você pode consolidar todos os metadados do DynamoDB em uma única tabela de lease usando o formato de tabela única.** Por padrão, o KCL 3.x cria três tabelas do DynamoDB para cada aplicativo: a tabela de leasing, a tabela de métricas do trabalhador e a tabela de estado do coordenador. O formato de tabela única reduz essas três tabelas para uma, o que ajuda a evitar os limites de tabelas no nível da conta do DynamoDB.
## Como funciona o formato de tabela única
No formato de tabela única, a KCL armazena as métricas do trabalhador e as entradas do estado do coordenador na tabela de locação junto com as entradas da locação. Cada item inclui um `entityType` atributo que distingue os diferentes tipos de registro.
As métricas do trabalhador e os itens do estado do coordenador usam a mesma estrutura de chave primária da tabela de locação, mas incluem um `entityType` valor distinto. Esse atributo permite que a KCL identifique a finalidade de cada item durante a digitalização da tabela.
Cada componente do KCL filtra as entradas necessárias para sua lógica de negócios com base no `entityType` atributo. Por exemplo, o Lease Assignment Manager (LAM) filtra as entradas de métricas de leasing e de trabalhadores para realizar a atribuição de leasing.
## Configurar formato de tabela única
A forma como você ativa o formato de tabela única depende da sua versão atual do KCL:
+ **Se você estiver usando o KCL 2.x:** siga o guia de migração atualizado para atualizar para o KCL 3.5. O formato de tabela única é usado por padrão para novas migrações da versão 2.x para a versão 3.5.
+ **Se você estiver usando o KCL 3.0—3.4:** você deve executar uma implantação em duas fases para migrar para o formato de tabela única. Veja as etapas de configuração e migração a seguir.
Para clientes existentes do KCL 3.x, defina a opção de `migrateAllEntitiesToLeaseTable` configuração em. `CoordinatorConfig` Essa opção controla se a KCL armazena todos os tipos de entidade de metadados na tabela de concessão.
**Valores de configuração para `migrar AllEntitiesToLeaseTable`**
| Valor | Padrão | Efeito |
| --- | --- | --- |
| false | Sim | A KCL usa tabelas separadas para métricas do trabalhador e estado do coordenador. O código do aplicativo suporta o formato de tabela única, mas não o ativa. |
| true | Não | A KCL começa a gravar as métricas dos trabalhadores e os dados do estado do coordenador na tabela de locação. Defina esse valor na implantação da Fase 2 após os `TableMigrationStatus` alcances `DEPLOYED` e você terá preparado para não haver regressões. |
A migração do KCL 3.x para o formato de tabela única requer uma implantação em duas fases:
1. **Fase 1:** Implantar o código KCL 3.5 atualizado com `migrateAllEntitiesToLeaseTable` definido como `false` (o padrão). Isso instala o novo código que suporta o formato de tabela única, mas não ativa a migração.
1. **Fase 2:** Depois que todos os trabalhadores executarem o novo código e os `TableMigrationStatus` alcances `DEPLOYED` e você tiver verificado que não há regressões, implante novamente com `migrateAllEntitiesToLeaseTable` set to `true` para iniciar a migração.
## Estados de migração
O `TableMigrationStateMachine` gerencia a transição do formato de várias tabelas para o formato de tabela única. O KCL rastreia o estado atual da migração em uma entrada separada do estado do coordenador chamada `TableMigration3.5` na tabela de estados do coordenador. Para obter a lista completa de estados, transições e descrições, consulte Estados de [migração de tabela única da KCL](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/migration/TableMigrationStatus.java).
**Estados de migração em formato de tabela única**
| Estado | Description | Condição de transição |
| --- | --- | --- |
| INIT | Estado inicial. Todos os trabalhadores estão emitindo o código mínimo de suporte nas estatísticas métricas do trabalhador. Os trabalhadores continuam emitindo métricas do trabalhador na tabela antiga e lendo as métricas do trabalhador e o estado do coordenador nas tabelas legadas e de locação. Funcionalmente, não há diferença entre INIT e DEPLOYED. | Todos os trabalhadores emitem o código de suporte mínimo de forma constante durante o tempo de cozimento. O aplicativo está pronto para passar para a implantação da Fase 2. |
| DEPLOYED | Todos os trabalhadores foram implantados com o novo código (Fase 1 concluída). O aplicativo suporta o formato de tabela única, mas não o ativou. | A implantação da fase 2 começa com `migrateAllEntitiesToLeaseTable` definido como`true`. |
| PENDING | Todos os trabalhadores executam o novo código. A KCL migra dados das métricas do trabalhador e das tabelas de estado do coordenador para a tabela de locação. | Um tempo de cozimento padrão de 24 horas termina após a conclusão da migração. |
| COMPLETE | A migração foi concluída. A KCL usa a tabela de lease exclusivamente para todas as leituras e gravações. As antigas métricas do trabalhador e as tabelas de estado do coordenador não são mais usadas. | Estado terminal. Nenhuma outra transição ocorre. |
Para obter informações detalhadas sobre cada estado, condições de transição e o comportamento completo da máquina de estado, consulte [Máquina de estado de migração de tabela única KCL](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/migration/TableMigrationStatus.java).
**nota**
O tempo de cozimento padrão entre os estados PENDING e COMPLETE é de 24 horas, mas você pode configurá-lo em até uma semana. Durante esse período, a KCL usa a tabela de concessão para todas as leituras e gravações, mas não exclui as tabelas antigas. Você deve excluir manualmente as métricas antigas do trabalhador e as tabelas de estado do coordenador depois de confirmar que a migração foi bem-sucedida. O KCL não exclui essas tabelas automaticamente.
## Considerações sobre reversão
O suporte à reversão depende da atual: `TableMigrationStatus`
+ **Durante a Fase 1** (`TableMigrationStatus`está `DEPLOYED` ou ainda não definida): você pode reverter com segurança para a versão anterior. O novo código é executado em um modo compatível com versões anteriores e nenhum dado foi gravado em entradas que não sejam de leasing na tabela de leasing.
+ **Durante a Fase 2** (`TableMigrationStatus`é `DEPLOYED` ou`PENDING`): você pode voltar para a Fase 1. Os trabalhadores voltam a usar as tabelas legadas (formato de várias tabelas) para métricas de trabalhadores e estado do coordenador. A migração está desfeita.
+ **Após o estado COMPLETO**: a reversão não é suportada. A KCL usa somente a tabela de concessão para todas as entidades. Mesmo que o código volte para a Fase 1, o trabalhador continua usando a tabela de concessão para todas as entidades e a configuração é ignorada.
**Atenção**
Depois que a migração atinge o estado COMPLETO, o aplicativo opera exclusivamente no modo de tabela única. A `migrateAllEntitiesToLeaseTable` configuração é ignorada e o KCL não volta a usar tabelas separadas. Certifique-se de que o tempo de cozimento antes de passar para COMPLETE seja suficiente, pois depois disso, mesmo uma reversão de código não volta para várias tabelas.
## Práticas recomendadas
Siga estas práticas recomendadas ao adotar o formato de tabela única:
+ Após a implantação da Fase 1, verifique se a entrada do estado do coordenador `TableMigration3.5` atinge `DEPLOYED` o status. Certifique-se de que não haja regressões antes de prosseguir para a Fase 2.
+ Monitore a `TableMigrationStatus` entrada estadual do `TableMigration3.5` coordenador para acompanhar o progresso nos estados IMPLANTADO, PENDENTE e COMPLETO. O status é armazenado na tabela de estados do coordenador como uma entrada separada (não na tabela de leasing) até que a migração seja CONCLUÍDA.
+ Certifique-se de que o tempo de cozimento antes de passar para COMPLETE seja suficiente, pois depois disso, mesmo uma reversão de código não volta para várias tabelas. O aplicativo funciona somente no modo de tabela única.
+ Depois que a migração for CONCLUÍDA, exclua manualmente as métricas antigas do trabalhador e as tabelas de estado do coordenador. O KCL não exclui essas tabelas automaticamente — ele apenas para de usá-las.
+ Se você tiver configurado `CoordinatorConfig.coordinatorStateTableConfig` ou`LeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig`, poderá remover essas configurações após a conclusão da migração. Essas configurações estão obsoletas no KCL 3.5 e versões posteriores.