View a markdown version of this page

Restauration par régression de la version précédente de la KCL - Amazon DynamoDB
Revenir de la phase 1 à KCL 1.xRevenir de la phase 2 à la phase 1Étape 1 : exécuter l’outil de migration de la KCLÉtape 2 : redéployer le code avec la configuration de phase 1 (facultatif)

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 comment restaurer votre application grand public KCL 3.5.x+ vers KCL 1.x. Le processus de restauration dépend de la phase de migration dans laquelle se trouve actuellement votre application.

Revenir de la phase 1 à KCL 1.x

Si votre application est en phase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), vous pouvez revenir à KCL 1.x en redéployant votre code précédent. La phase 1 est rétrocompatible avec KCL 1.x 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 1.x pour tous les travailleurs.

Important

La phase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) est un changement décisif pour la restauration. Une fois que votre application entre dans la phase 2, les entrées non liées au bail (WORKER_METRIC_STATSetMigration3.0) sont écrites dans la table des baux qui ne sont pas rétrocompatibles avec KCL 1.x. Cela empêche définitivement un retour direct à KCL 1.x. Nous vous recommandons vivement de préparer votre application en phase 1 pendant une période prolongée afin de valider la stabilité avant de passer à la phase 2.

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 sur le GitHub site Web pour revenir à la phase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1). Il s'agit d'un processus en deux étapes :

  1. Exécutez l'outil de migration KCL sur le GitHub site Web.

  2. 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 à KCL 1.x). L'outil de migration KCL gère uniquement la restauration de la phase 2 à la phase 1. L'outil ne supprime pas les entrées non liées à un contrat de location de la table des contrats de location. Ces entrées ne sont pas rétrocompatibles avec KCL 1.x, c'est pourquoi une restauration à deux niveaux de la phase 2 directement vers KCL 1.x 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 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), 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.

  • Ainsi, tous les workers peuvent s’exécuter dans un mode compatible avec la KCL 1.x et commencer à utiliser l’algorithme d’équilibrage de charge utilisé dans les versions précédentes de la KCL. Si vous rencontrez des problèmes avec le nouvel algorithme d'équilibrage de charge de KCL 3.5.x+, le problème est immédiatement résolu.

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 1.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 dans le répertoire des scripts du référentiel KCL GitHub. Exécutez le script à partir de l'un de vos collaborateurs ou de tout hôte disposant des autorisations requises pour écrire et mettre à jour la table des baux. Assurez-vous que les autorisations IAM appropriées sont configurées pour les applications consommateur KCL. Vous ne devez exécuter le script qu'une seule fois par application KCL. Exécutez l'outil de migration KCL à l'aide de la commande suivante :

python3 ./KclMigrationTool.py --region region --mode rollback [--application_name applicationName] [--lease_table_name leaseTableName]

Parameters

--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

Ce paramètre est nécessaire si 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

« Restauration par régression 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 collaborateurs fonctionnaient en mode compatible avec KCL 1.x (la phase 2 n'était pas encore passée automatiquement à l'équilibrage de charge 3.x complet). 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

« Restauration par régression 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 étaient passés automatiquement à l'équilibrage de charge complet de KCL 3.x et l'outil de migration KCL les a replacés en mode compatible avec KCL 1.x. 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 une configuration de phase 1 () CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1 auprès de vos collaborateurs.