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.
| 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 |
A migração do KCL 3.x para o formato de tabela única requer uma implantação em duas fases:
-
Fase 1: Implantar o código KCL 3.5 atualizado com
migrateAllEntitiesToLeaseTabledefinido comofalse(o padrão). Isso instala o novo código que suporta o 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
TableMigrationStatusalcancesDEPLOYEDe você tiver verificado que não há regressões, implante novamente commigrateAllEntitiesToLeaseTableset totruepara 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
| 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 |
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
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 (
TableMigrationStatusestáDEPLOYEDou 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éDEPLOYEDouPENDING): 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.5atingeDEPLOYEDo status. Certifique-se de que não haja regressões antes de prosseguir para a Fase 2. -
Monitore a
TableMigrationStatusentrada estadual doTableMigration3.5coordenador 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.coordinatorStateTableConfigouLeaseManagementConfig.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.
