View a markdown version of this page

Restauración de la versión de KCL anterior - Amazon DynamoDB
Retroceda de la fase 1 a la versión 1.x de KCLRetroceso de la fase 2 a la fase 1Paso 1: ejecución de la herramienta de migración de KCLPaso 2: volver a implementar el código con la configuración de la fase 1 (opcional)

Restauración de la versión de KCL anterior

En este tema se explica cómo revertir la aplicación de consumidor de KCL 3.5.x+ a KCL 1.x. El proceso de reversión depende de la fase de migración en la que se encuentre actualmente la aplicación.

Retroceda de la fase 1 a la versión 1.x de KCL

Si la aplicación se encuentra en la fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), puede volver a KCL 1.x volviendo a implementar el código anterior. La fase 1 es compatible con la versión anterior de KCL 1.x y no crea ninguna entrada específica para la migración en la tabla de arrendamientos. No se necesita ninguna herramienta de migración. Para retroceder desde la fase 1, vuelva a implementar el código con la versión 1.x de KCL para todos los trabajadores.

importante

La fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) es un cambio importante para la reversión. Una vez que la aplicación entra en la fase 2, las entradas que no son de arrendamiento (WORKER_METRIC_STATS y Migration3.0) se escriben en la tabla de arrendamientos y no son compatibles con versiones anteriores de KCL 1.x. Esto evita permanentemente una reversión directa a KCL 1.x. Recomendamos encarecidamente mantener la aplicación en la fase 1 durante un periodo prolongado para validar la estabilidad antes de pasar a la fase 2.

Retroceso de la fase 2 a la fase 1

Si la aplicación se encuentra en la fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X), debe usar la herramienta de migración de KCL en el sitio web de GitHub para volver a la fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1). Se trata de un proceso de dos partes:

  1. Ejecute la herramienta de migración de KCL en el sitio web de GitHub.

  2. Vuelva a implementar el código con la configuración de la fase 1 (opcional).

importante

No se pueden revertir dos niveles (de la fase 2 a la fase 1 y, después, a KCL 1.x). La herramienta de migración de KCL solo gestiona la reversión de la fase 2 a la fase 1. La herramienta no elimina las entradas que no sean de arrendamiento de la tabla de arrendamientos. Estas entradas no son compatibles con versiones anteriores de KCL 1.x, por lo que no es posible realizar una reversión en dos niveles directamente de la fase 2 a KCL 1.x.

Paso 1: ejecución de la herramienta de migración de KCL

Cuando necesite revertir de la fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) a la fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), ejecute la herramienta de migración de KCL. La herramienta realiza las siguientes tareas:

  • Elimina el índice secundario global (LeaseOwnerToLeaseKeyIndex) de la tabla de arrendamiento en DynamoDB. Este índice lo crea KCL 3.5.x+, pero no es necesario al revertir a la fase 1.

  • Hace que todos los procesos de trabajo se ejecuten en un modo compatible con KCL 1.x y comiencen a utilizar el algoritmo de equilibrio de carga utilizado en versiones anteriores de KCL. Si tiene problemas con el nuevo algoritmo de equilibrio de carga en KCL 3.5.x+, esto mitiga el problema inmediatamente.

importante

La entrada de estado del coordinador (Migration3.0) en la tabla de arrendamientos no se debe eliminar durante el proceso de migración, restauración y avance.

nota

Todos los trabajadores de la aplicación de consumo deben usar el mismo algoritmo de equilibrio de carga en un momento dado. La herramienta de migración de KCL se asegura de que todos los procesos de trabajo de la aplicación de consumo KCL 3.5.x+ cambien al modo compatible con KCL 1.x, de modo que todos los procesos de trabajo ejecuten el mismo algoritmo de equilibrio de carga durante la implementación progresiva de vuelta a la fase 1.

Puede descargar la herramienta de migración de KCL en el directorio de scripts del repositorio de GitHub de KCL. Ejecute el script desde cualquiera de los procesos de trabajo o desde cualquier host que tenga los permisos necesarios para escribir y actualizar la tabla de arrendamientos. Asegúrese de que los permisos de IAM adecuados estén configurados para las aplicaciones de consumo de KCL. Debe ejecutar el script solo una vez por aplicación de KCL. Ejecute la herramienta de migración de KCL con el siguiente comando:

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

Parameters

--region

Sustituya region por su Región de AWS.

--application_name

Este parámetro es obligatorio si utiliza el nombre predeterminado para la tabla de arrendamientos. Si ha especificado un nombre personalizado para la tabla de arrendamientos, puede omitir este parámetro. Reemplace applicationName por el nombre de la aplicación de KCL real. La herramienta utiliza este nombre para derivar el nombre de tabla predeterminado si no se proporciona un nombre personalizado.

--lease_table_name

Este parámetro es necesario cuando ha establecido un nombre personalizado para la tabla de arrendamientos en la configuración de KCL. Si utiliza el nombre de tabla predeterminado, puede omitir este parámetro. Reemplace leaseTableName por el nombre de tabla personalizado que especificó para la tabla de arrendamiento.

Paso 2: volver a implementar el código con la configuración de la fase 1 (opcional)

Tras ejecutar la herramienta de migración de KCL para una reversión de la fase 2 a la fase 1, verá uno de estos mensajes:

Mensaje 1

“Reversión completada. La aplicación estaba ejecutando la funcionalidad de fase 2 (compatible con 2x). Regrese a la fase 1 implementando la aplicación KCL 3.5.x con la configuración de la fase 1”.

Acción necesaria: los trabajadores estaban funcionando en modo compatible con KCL 1.x (la fase 2 aún no había realizado la transición automática al equilibrio de carga completo de 3.x). Vuelva a implementar la aplicación KCL 3.5.x+ con la configuración de fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) entre los trabajadores.

Mensaje 2

“Reversión completada. La aplicación de KCL estaba ejecutando la funcionalidad de fase 2 (3x) y ha vuelto al modo de fase 2 (compatible con 2x). Si no observa ninguna mejora tras un breve periodo de tiempo, regrese a la fase 1 implementando la aplicación de KCL 3.5.x con la configuración de la fase 1”.

Acción necesaria: los trabajadores han realizado la transición automática al equilibrio de carga completo de KCL 3.x y la herramienta de migración de KCL los ha cambiado de nuevo al modo compatible con KCL 1.x. Si el problema se resuelve, no es necesario volver a implementar. Si el problema persiste, vuelva a implementar la aplicación KCL 3.5.x+ con la configuración de fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) entre los trabajadores.