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.
Restauration par régression de la version précédente de la KCL
Cette rubrique explique les étapes à suivre pour revenir à la version précédente de votre client KCL 3.5.x. Le processus de restauration dépend de la phase de migration dans laquelle se trouve actuellement votre application.
Important
L'outil de migration KCL n'est requis que lors du retour de la phase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) à la phase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1). Si votre application est toujours en phase 1, vous pouvez revenir à votre version KCL précédente en redéployant votre code précédent sans exécuter l'outil.
Revenir de la phase 1 à la version précédente de KCL
Si votre application est en phase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), vous pouvez revenir à votre version KCL précédente en redéployant votre code précédent. La phase 1 est rétrocompatible avec les versions précédentes de KCL et ne crée aucune entrée spécifique à la migration dans le tableau des baux. Aucun outil de migration n'est nécessaire.
Pour revenir à la phase 1 :
-
Redéployez le code avec votre version KCL précédente pour tous les travailleurs.
Revenir de la phase 2 à la phase 1
Si votre application est en phase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X), vous devez utiliser l'outil de migration KCL pour revenir à la phase 1. Il s'agit d'un processus en deux étapes :
-
Exécuter l’outil de migration de la KCL
-
Redéployez le code avec la configuration de phase 1 (facultatif).
Important
Vous ne pouvez pas revenir en arrière de deux niveaux (de la phase 2 à la phase 1, puis à la version précédente de KCL). L'outil de migration KCL gère uniquement la restauration de la phase 2 à la phase 1.
Note
L'outil de migration KCL ne supprime pas les entrées non liées au bail de la table des baux. Ces entrées ne sont pas rétrocompatibles avec les versions précédentes de KCL. C'est pourquoi un retour à deux niveaux de la phase 2 directement à une version précédente de KCL n'est pas possible.
Étape 1 : exécuter l’outil de migration de la KCL
Lorsque vous devez revenir de la phase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) à la phase 1, exécutez l'outil de migration KCL. L'outil exécute les tâches suivantes :
-
Il supprime l'index secondaire global (LeaseOwnerToLeaseKeyIndex) de la table des baux dans DynamoDB. Cet index est créé par KCL 3.5.x mais n'est pas nécessaire lorsque vous revenez à la phase 1.
-
Cela permet à tous les travailleurs de fonctionner dans un mode compatible avec KCL 2.x et de commencer à utiliser l'algorithme d'équilibrage de charge utilisé dans les versions précédentes de KCL. Si vous rencontrez des problèmes avec le nouvel algorithme d'équilibrage de charge de KCL 3.5.x, cela résout immédiatement le problème.
Important
L'entrée d'état du coordinateur (Migration3.0) dans la table des baux ne doit pas être supprimée pendant les processus de migration, d'annulation et de report.
Note
Tous les travailleurs de votre application grand public doivent utiliser le même algorithme d'équilibrage de charge à un moment donné. L'outil de migration KCL garantit que tous les travailleurs de votre application grand public KCL 3.5.x passent en mode compatible avec KCL 2.x afin que tous les travailleurs exécutent le même algorithme d'équilibrage de charge lors du retour à la phase 1 du déploiement.
Vous pouvez télécharger l'outil de migration KCL
python3 ./KclMigrationTool.py --region <region> --mode rollback [--application_name <applicationName>] [--lease_table_name <leaseTableName>]
Paramètres
-
--region : remplacez
<region>par votre. Région AWS -
--application_name : Ce paramètre est obligatoire si vous utilisez le nom par défaut pour votre table de baux. Si vous avez spécifié un nom personnalisé pour la table des baux, vous pouvez omettre ce paramètre. Remplacez-le
<applicationName>par le nom actuel de votre application KCL. L'outil utilise ce nom pour dériver le nom de table par défaut si aucun nom personnalisé n'est fourni. -
--lease_table_name (facultatif) : ce paramètre est nécessaire lorsque vous avez défini un nom personnalisé pour la table des baux dans votre configuration KCL. Si vous utilisez le nom de table par défaut, vous pouvez omettre ce paramètre. Remplacez-le
<leaseTableName>par le nom de table personnalisé que vous avez spécifié pour votre tableau des baux.
Étape 2 : redéployer le code avec la configuration de phase 1 (facultatif)
Après avoir exécuté l'outil de migration KCL pour revenir de la phase 2 à la phase 1, l'un des messages suivants s'affiche :
-
Message 1 : « La restauration est terminée. Votre application exécutait la fonctionnalité Phase 2 (compatible 2x). Revenez à la phase 1 en déployant votre application KCL 3.5.x avec la configuration de phase 1. »
-
Action requise : Vos travailleurs fonctionnaient en mode Phase 2 (compatible 2x). Redéployez votre application KCL 3.5.x avec une configuration de phase 1 (
CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) pour vos employés.
-
-
Message 2 : « La restauration est terminée. Votre application KCL exécutait la fonctionnalité Phase 2 (3x) et a été ramenée en mode Phase 2 (compatible 2x). Si vous ne constatez aucune atténuation après une courte période, revenez à la phase 1 en déployant votre application KCL 3.5.x avec la configuration de phase 1. »
-
Action requise : Vos collaborateurs fonctionnaient en mode Phase 2 (3x) et l'outil de migration KCL les a ramenés en mode Phase 2 (compatible 2x). Si le problème est résolu, il n'est pas nécessaire de procéder à un redéploiement. Si le problème persiste, redéployez votre application KCL 3.5.x avec la configuration de phase 1 (
CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) auprès de vos collaborateurs.
-
