Como funciona o formato de tabela única Configurar formato de tabela única Estados de migração Métricas de migração Considerações sobre reversão Práticas recomendadas

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 locação 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 locação, a tabela de métricas do trabalhador e a tabela de estados do coordenador. O formato de tabela única reduz essas três tabelas a uma, o que ajuda a evitar limites de tabela no nível da conta do DynamoDB.

Como funciona o formato de tabela única

Em formato de tabela única, a KCL armazena as métricas dos trabalhadores 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 de 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 locação e trabalhador 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 fazer o upgrade para o KCL 3.5. O formato de tabela única é usado por padrão para novas migrações de 2.x para 3.5.
Se você estiver no KCL 3.0—3.4: você deve realizar 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 entidades 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 de trabalhadores 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 escrever 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ê não terá nenhuma regressão.

A migração do KCL 3.x para o formato de tabela única requer uma implantação em duas fases:

Fase 1: implante o código KCL 3.5 atualizado com migrateAllEntitiesToLeaseTable definido como false (o padrão). Isso instala o novo código que oferece suporte ao formato de tabela única, mas não ativa a migração.
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.

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 dos trabalhadores. Os trabalhadores continuam emitindo métricas de trabalhadores na tabela legada e lendo as métricas dos trabalhadores e o estado do coordenador nas tabelas legada e de locação. Funcionalmente, não há diferença entre INIT e DEPLOYED.	Todos os trabalhadores emitem o código mínimo de suporte de forma constante durante o tempo de cozimento. O aplicativo está pronto para passar para a Fase 2 de implantação.
`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 tabelas de métricas do trabalhador e do estado do coordenador para a tabela de locação.	Um tempo de cozimento padrão de 24 horas decorre após a conclusão da migração.
`COMPLETE`	A migração foi concluída. A KCL usa a tabela de leasing exclusivamente para todas as leituras e gravações. As antigas tabelas de métricas do trabalhador e do 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 estados, consulte Máquina de estado de migração de tabela única KCL.

nota

O tempo de cozimento padrão entre os estados PENDENTE e COMPLETO é 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 antigas tabelas de métricas do trabalhador e do estado do coordenador depois de confirmar que a migração foi bem-sucedida. A KCL não exclui essas tabelas automaticamente.

Métricas de migração

Com a KCL, você pode monitorar o progresso e a integridade da migração de uma única tabela usando CloudWatch métricas. Use essas métricas para confirmar se os trabalhadores adotaram o novo código e para acompanhar a migração à medida que ela passa por seus estados. Você também pode detectar falhas de leitura, gravação ou exclusão do DynamoDB durante a migração. As tabelas a seguir agrupam as métricas pela operação KCL (dimensão métrica) que as emite e por quando cada métrica é emitida.

O trabalhador líder eleito emite continuamente as seguintes métricas, independentemente de a migração estar em andamento:

Métricas emitidas pelo líder em todos os momentos
Operation	Métrica	Unidade	Description
`TableMigration`	`StatusOrdinal`	Nenhum	Ordinal do status atual da migração do DynamoDB: `0` = UNKNOWN, = INIT, `1` = DEPLOYED, `2` = PENDING, `3` = COMPLETE. `4`
`WorkerMetrics`	`FleetMinSupportCode`	Nenhum	Código mínimo de suporte para todos os trabalhadores arrendatários da frota.

O trabalhador líder eleito emite as seguintes métricas somente enquanto a migração está em andamento:

Métricas emitidas pelo líder durante a migração
Operation	Métrica	Unidade	Description
`TableMigration`	`Phase1Worker`	Contagem	Número de trabalhadores que suportam a operação com uma única tabela do DynamoDB, mas ainda não migraram para usar a tabela única.
`TableMigration`	`Phase2Worker`	Contagem	Número de trabalhadores que migraram para escrever em uma única tabela. Esses trabalhadores ainda podem ler de várias tabelas até que a migração da tabela seja concluída.
`TableMigration`	`PrePhase1Worker`	Contagem	Número de trabalhadores em uma versão anterior à 3.5 que não suportam a operação em uma única tabela do DynamoDB.
`TableMigration`	`WriteFault`	Contagem	`1`em caso de falha de gravação do DynamoDB, `0` em caso de sucesso.
`TableMigration`	`DeleteFault`	Contagem	`1`em caso de falha de exclusão do DynamoDB, `0` em caso de sucesso.
`TableMigration`	`CompletionFault`	Contagem	`1`quando a gravação transacional do `COMPLETE` status falha, `0` em caso de sucesso.
`TableMigrationAsyncMove`	`Success`	Contagem	`1`em uma movimentação transacional bem-sucedida de CoordinatorState entradas, `0` em caso de falha.
`TableMigrationAsyncMove`	`Time`	Milissegundos	Duração da operação de movimentação assíncrona.
`TableMigrationAsyncMove`	`BatchCount`	Contagem	Número de lotes que foram movidos com sucesso.

Todos os trabalhadores emitem as seguintes métricas enquanto a migração está em andamento:

Métricas emitidas por todos os trabalhadores durante a migração
Operation	Métrica	Unidade	Description
`TableMigration`	`ReadFault`	Contagem	`1`em caso de falha na leitura `TableMigrationState` do DynamoDB, `0` em caso de sucesso.
`TableMigration`	`Time`	Milissegundos	Duração da execução da máquina de estado.
`TableMigrationInitialize`	`Success`	Contagem	`1`em uma inicialização bem-sucedida, `0` em caso de falha.
`TableMigrationInitialize`	`Time`	Milissegundos	Duração da operação de inicialização.

Use essas métricas para decidir quando avançar na migração. Quando StatusOrdinal está consistentemente 2 (IMPLANTADO) e PrePhase1Worker está0, todos os trabalhadores suportam o formato de tabela única e você pode passar para a fase 2 da implantação da migração de tabelas. Depois de StatusOrdinal alcançar 4 (CONCLUIR), você pode excluir com segurança as tabelas legadas.

Considerações sobre reversão

O suporte à reversão depende do atual: TableMigrationStatus

Durante a Fase 1 (TableMigrationStatusestá 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 concessão na tabela de concessão.
Durante a Fase 2 (TableMigrationStatusé DEPLOYED ouPENDING): Você pode reverter para a Fase 1. Os trabalhadores voltam a usar as tabelas legadas (formato de várias tabelas) para métricas dos trabalhadores e estado do coordenador. A migração foi desfeita.
Após o estado COMPLETO: A reversão não é suportada. A KCL usa somente a tabela de leasing para todas as entidades. Mesmo que o código volte para a Fase 1, o trabalhador continua usando a tabela de leasing 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 a KCL não volta a usar tabelas separadas. Certifique-se de que o tempo de cozimento antes de passar para COMPLETE seja suficiente, porque 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 entrada TableMigrationStatus no estado 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 concessão) até que a migração seja CONCLUÍDA.
Certifique-se de que o tempo de cozimento antes de passar para COMPLETE seja suficiente, porque 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 estados do coordenador. A KCL não exclui essas tabelas automaticamente — ela apenas para de usá-las.
Se você tiver configurado CoordinatorConfig.coordinatorStateTableConfig ouLeaseManagementConfig.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.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Política de ciclo de vida da versão da KCL

Migrar de versões anteriores da KCL