Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Format de tableau unique pour KCL
À partir de KCL 3.5, vous pouvez consolider toutes les métadonnées de DynamoDB dans une seule table de bail à l'aide du format de tableau unique. Par défaut, KCL 3.x crée trois tables DynamoDB pour chaque application : la table des baux, la table des métriques des travailleurs et la table des états des coordinateurs. Le format de tableau unique réduit ces trois tableaux à un seul, ce qui vous permet d'éviter les limites de tables au niveau du compte DynamoDB.
Comment fonctionne le format de tableau unique
Dans un format de tableau unique, KCL stocke les indicateurs des travailleurs et les entrées d'état du coordinateur dans le tableau des baux, à côté des entrées de bail. Chaque élément comprend un entityType attribut qui permet de distinguer les différents types d'enregistrement.
Les métriques relatives aux travailleurs et les éléments d'état du coordinateur utilisent la même structure de clé primaire que la table des baux, mais incluent une entityType valeur distincte. Cet attribut permet à KCL d'identifier l'objectif de chaque élément lors de l'analyse des tableaux.
Chaque composant de KCL filtre les entrées dont il a besoin pour sa logique métier en fonction de l'entityTypeattribut. Par exemple, le Lease Assignment Manager (LAM) filtre les entrées des mesures relatives aux contrats de location et aux travailleurs afin d'effectuer l'attribution des baux.
Configurer le format de tableau unique
La façon dont vous activez le format de tableau unique dépend de votre version KCL actuelle :
-
Si vous utilisez KCL 2.x : suivez le guide de migration mis à jour pour passer à KCL 3.5. Le format de tableau unique est utilisé par défaut pour les nouvelles migrations de 2.x vers 3.5.
-
Si vous utilisez KCL 3.0—3.4 : vous devez effectuer un déploiement en deux phases pour migrer vers le format de table unique. Consultez les étapes de configuration et de migration suivantes.
Pour les clients KCL 3.x existants, définissez l'option de migrateAllEntitiesToLeaseTable configuration dans. CoordinatorConfig Cette option contrôle si KCL stocke tous les types d'entités de métadonnées dans la table des baux.
| Value | Par défaut | Effet |
|---|---|---|
false |
Oui |
KCL utilise des tableaux distincts pour les indicateurs des travailleurs et l'état du coordinateur. Le code de l'application prend en charge le format de tableau unique mais ne l'active pas. |
true |
Non |
KCL commence à écrire les métriques des travailleurs et les données sur l'état des coordinateurs dans le tableau des baux. Définissez cette valeur lors du déploiement de la phase 2 une fois les |
La migration de KCL 3.x vers le format de table unique nécessite un déploiement en deux phases :
-
Phase 1 : Déployez le code KCL 3.5 mis à jour avec
migrateAllEntitiesToLeaseTabledéfini surfalse(valeur par défaut). Cela installe le nouveau code qui prend en charge le format de table unique mais n'active pas la migration. -
Phase 2 : une fois que tous les travailleurs ont exécuté le nouveau code et le
TableMigrationStatusreachDEPLOYED, et que vous avez vérifié qu'il n'y a pas de régressions, déployez à nouveau avecmigrateAllEntitiesToLeaseTablesettrueto pour commencer la migration.
États migratoires
TableMigrationStateMachineGère la transition du format multi-tableaux au format tableau unique. KCL suit l'état actuel de la migration dans une entrée d'état du coordinateur distincte appelée TableMigration3.5 dans la table des états du coordinateur. Pour obtenir la liste complète des états, des transitions et des descriptions, consultez la section États de migration à table unique
| State | Description | État de transition |
|---|---|---|
INIT |
État initial. Tous les travailleurs émettent le code de soutien minimum dans les statistiques métriques des travailleurs. Les employés continuent d'émettre des métriques sur les travailleurs dans la table héritée et de lire les métriques des travailleurs et l'état du coordinateur à la fois dans les anciennes tables et sur les baux. Sur le plan fonctionnel, il n'y a aucune différence entre INIT et DEPLOYED. |
Tous les travailleurs émettent régulièrement le code de support minimum pendant le temps de cuisson. L'application est prête à passer à la phase 2 du déploiement. |
DEPLOYED |
Tous les travailleurs ont été déployés avec le nouveau code (phase 1 terminée). L'application prend en charge le format de tableau unique mais ne l'a pas activé. |
La phase 2 du déploiement commence par |
PENDING |
Tous les travailleurs exécutent le nouveau code. KCL migre les données des tableaux de métriques des travailleurs et des états des coordinateurs vers la table des baux. |
Un délai de cuisson par défaut de 24 heures s'écoule une fois la migration terminée. |
COMPLETE |
La migration est terminée. KCL utilise le tableau des baux exclusivement pour toutes les lectures et écritures. Les anciennes métriques des travailleurs et les tables d'état des coordinateurs ne sont plus utilisées. |
État du terminal. Aucune autre transition ne se produit. |
Pour des informations détaillées sur chaque état, les conditions de transition et le comportement complet de la machine à états, voir Machine d'état de migration à table unique
Note
Le temps de cuisson par défaut entre les états PENDING et COMPLETE est de 24 heures, mais vous pouvez le configurer jusqu'à une semaine. Pendant cette période, KCL utilise la table de bail pour toutes les lectures et écritures, mais ne supprime pas les anciennes tables. Vous devez supprimer manuellement les anciennes tables de métriques de travail et d'état des coordinateurs après avoir confirmé la réussite de la migration. KCL ne supprime pas ces tables automatiquement.
Métriques de migration
Avec KCL, vous pouvez suivre la progression et l'état de la migration de la table unique à l'aide de CloudWatch métriques. Utilisez ces indicateurs pour confirmer que les travailleurs ont adopté le nouveau code et pour suivre la migration au fur et à mesure de son évolution. Vous pouvez également détecter les erreurs de lecture, d'écriture ou de suppression de DynamoDB lors de la migration. Les tableaux suivants regroupent les métriques selon l'opération KCL (dimension métrique) qui les émet et selon le moment où chaque métrique est émise.
Le leader élu émet en permanence les indicateurs suivants, qu'une migration soit en cours ou non :
Opération |
Métrique |
Unité |
Description |
|---|---|---|---|
|
|
Aucune |
Ordinal de l'état de migration DynamoDB actuel : |
|
|
Aucune |
Code d'assistance minimum pour tous les travailleurs de la flotte qui sont propriétaires d'un contrat de location. |
Le collaborateur leader élu émet les mesures suivantes uniquement lorsqu'une migration est en cours :
Opération |
Métrique |
Unité |
Description |
|---|---|---|---|
|
|
Nombre |
Nombre de travailleurs qui prennent en charge le fonctionnement avec une seule table DynamoDB mais qui n'ont pas encore migré vers l'utilisation de cette table unique. |
|
|
Nombre |
Nombre de travailleurs ayant migré vers l'écriture dans la table unique. Ces travailleurs peuvent continuer à lire à partir de plusieurs tables jusqu'à la fin de la migration des tables. |
|
|
Nombre |
Nombre de travailleurs sur une version antérieure à 3.5 qui ne peuvent pas prendre en charge le fonctionnement sur une seule table DynamoDB. |
|
|
Nombre |
|
|
|
Nombre |
|
|
|
Nombre |
|
|
|
Nombre |
|
|
|
Millisecondes |
Durée de l'opération de déplacement asynchrone. |
|
|
Nombre |
Nombre de lots déplacés avec succès. |
Tous les travailleurs émettent les mesures suivantes lorsqu'une migration est en cours :
Opération |
Métrique |
Unité |
Description |
|---|---|---|---|
|
|
Nombre |
|
|
|
Millisecondes |
Durée de fonctionnement de la machine d'état. |
|
|
Nombre |
|
|
|
Millisecondes |
Durée de l'opération d'initialisation. |
Utilisez ces indicateurs pour décider quand faire avancer la migration. Lorsque StatusOrdinal c'est constant 2 (DÉPLOYÉ) et PrePhase1Worker qu'il l'est0, tous les travailleurs prennent en charge le format de tableau unique, et vous pouvez passer à la phase 2 du déploiement de la migration des tables. Une fois StatusOrdinal que vous avez atteint 4 (TERMINÉ), vous pouvez supprimer les anciennes tables en toute sécurité.
Considérations relatives à la restauration
La prise en charge de la restauration dépend de la situation actuelle TableMigrationStatus :
-
Pendant la phase 1 (
TableMigrationStatusdéfinieDEPLOYEDou pas encore) : vous pouvez revenir à la version précédente en toute sécurité. Le nouveau code s'exécute en mode rétrocompatible et aucune donnée n'a été écrite dans les entrées non liées au bail dans la table des baux. -
Pendant la phase 2 (
TableMigrationStatusc'estDEPLOYEDouPENDING) : vous pouvez revenir à la phase 1. Les travailleurs recommencent à utiliser les anciennes tables (format multi-tableaux) pour les métriques des travailleurs et l'état du coordinateur. La migration est annulée. -
Après l'état COMPLET : la restauration n'est pas prise en charge. KCL utilise uniquement le tableau des baux pour toutes les entités. Même si le code revient à la phase 1, le travailleur continue à utiliser la table des baux pour toutes les entités et la configuration est ignorée.
Avertissement
Une fois la migration terminée, l'application fonctionne exclusivement en mode table unique. La migrateAllEntitiesToLeaseTable configuration est ignorée et KCL ne revient pas à l'utilisation de tables séparées. Assurez-vous que le temps de cuisson avant de passer à COMPLETE est suffisant, car après cela, même une restauration du code ne permet pas de revenir à plusieurs tables.
Bonnes pratiques
Suivez ces bonnes pratiques lorsque vous adoptez le format de tableau unique :
-
Après le déploiement de la phase 1, vérifiez que l'entrée d'état du coordinateur
TableMigration3.5atteintDEPLOYEDle statut. Assurez-vous qu'il n'y a pas de régressions avant de passer à la phase 2. -
Surveillez l'entrée
TableMigrationStatusdans l'état duTableMigration3.5coordinateur pour suivre la progression dans les états DÉPLOYÉ, EN ATTENTE et COMPLET. Le statut est enregistré dans la table des états du coordinateur en tant qu'entrée distincte (et non dans la table des baux) jusqu'à ce que la migration soit terminée. -
Assurez-vous que le temps de cuisson avant de passer à COMPLETE est suffisant, car après cela, même une restauration du code ne permet pas de revenir à plusieurs tables. L'application fonctionne uniquement en mode tableau unique.
-
Une fois la migration terminée, supprimez manuellement les anciennes métriques des travailleurs et les tables d'état des coordinateurs. KCL ne supprime pas ces tables automatiquement ; il arrête simplement de les utiliser.
-
Si vous avez configuré
CoordinatorConfig.coordinatorStateTableConfigouLeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig, vous pouvez supprimer ces configurations une fois la migration terminée. Ces configurations sont obsolètes dans KCL 3.5 et versions ultérieures.
