Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Restauración de la versión de KCL anterior
En este tema se explican los pasos para hacer que su consumidor KCL 3.5.x retroceda a la versión anterior. El proceso de reversión depende de la fase de migración en la que se encuentre actualmente su aplicación.
importante
La herramienta de migración KCL solo es necesaria para retroceder de la fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) a la fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1). Si su aplicación aún se encuentra en la fase 1, puede volver a la versión anterior de KCL redistribuyendo el código anterior sin ejecutar la herramienta.
Vuelva de la fase 1 a la versión anterior de KCL
Si su aplicación está en la fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), puede volver a la versión anterior de KCL redistribuyendo el código anterior. La fase 1 es retrocompatible con las versiones anteriores de KCL y no crea ninguna entrada específica para la migración en la tabla de concesiones. No se necesita ninguna herramienta de migración.
Para retroceder desde la fase 1:
-
Vuelva a implementar el código de la versión anterior de KCL en todos los trabajadores.
Vuelva de la fase 2 a la fase 1
Si su solicitud se encuentra en la fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X), debe usar la herramienta de migración de KCL para volver a la fase 1. Se trata de un proceso de dos partes:
-
Ejecución de la herramienta de migración de KCL
. -
Vuelva a implementar el código con la configuración de la fase 1 (opcional).
importante
No puede revertir dos niveles (de la fase 2 a la fase 1 y, después, a la versión anterior de KCL). La herramienta de migración de KCL solo gestiona la reversión de la fase 2 a la fase 1.
nota
La herramienta de migración de KCL no elimina las entradas que no son de arrendamiento de la tabla de arrendamientos. Estas entradas no son compatibles con versiones anteriores de KCL, por lo que no es posible volver directamente de la fase 2 a una versión anterior de KCL en dos niveles.
Paso 1: ejecución de la herramienta de migración de KCL
Cuando necesite volver de la fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) a la fase 1, ejecute la herramienta de migración de KCL. La herramienta realiza las siguientes tareas:
-
Elimina el índice secundario global (LeaseOwnerToLeaseKeyIndex) de la tabla de arrendamientos de DynamoDB. Este índice lo crea KCL 3.5.x, pero no es necesario para volver a la fase 1.
-
Hace que todos los trabajadores funcionen en un modo compatible con KCL 2.x y comiencen a utilizar el algoritmo de equilibrio de carga utilizado en las versiones anteriores de KCL. Si tiene problemas con el nuevo algoritmo de equilibrio de carga de KCL 3.5.x, esto mitiga el problema de inmediato.
importante
La entrada del estado del coordinador (Migration3.0) en la tabla de concesiones no se debe eliminar durante el proceso de migración, reversión y reversión.
nota
Todos los trabajadores de tu aplicación para consumidores deben usar el mismo algoritmo de equilibrio de carga en un momento dado. La herramienta de migración de KCL garantiza que todos los trabajadores de su aplicación de consumo KCL 3.5.x cambien al modo compatible con KCL 2.x, de modo que todos los trabajadores ejecuten el mismo algoritmo de equilibrio de carga durante el proceso de implementación gradual que vuelve a la fase 1.
Puede descargar la herramienta de migración de KCL
python3 ./KclMigrationTool.py --region <region> --mode rollback [--application_name <applicationName>] [--lease_table_name <leaseTableName>]
Parámetros
-
--region: Sustituir por
<region>su. Región de AWS -
--application_name: este parámetro es obligatorio si utilizas el nombre predeterminado para tu tabla de arrendamientos. Si has especificado un nombre personalizado para la tabla de arrendamientos, puedes omitir este parámetro. Reemplace
<applicationName>por el nombre de la aplicación KCL. La herramienta usa este nombre para derivar el nombre predeterminado de la tabla si no se proporciona un nombre personalizado. -
--lease_table_name (opcional): este parámetro es necesario cuando se ha establecido un nombre personalizado para la tabla de arrendamiento 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: Vuelva a implementar el código con la configuración de la fase 1 (opcional)
Tras ejecutar la herramienta de migración de KCL para pasar de la fase 2 a la fase 1, aparecerá uno de los siguientes mensajes:
-
Mensaje 1: «Se completó la reversión. Su aplicación estaba ejecutando la funcionalidad de la fase 2 (compatible con el doble de veces). Vuelva a la fase 1 implementando su aplicación KCL 3.5.x con la configuración de la fase 1».
-
Acción requerida: Sus trabajadores estaban trabajando en el modo de fase 2 (compatible con 2 veces). Vuelva a implementar su aplicación KCL 3.5.x con la configuración de fase 1 ()
CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1para sus trabajadores.
-
-
Mensaje 2: «Se completó la reversión. Su aplicación KCL ejecutaba la funcionalidad de la fase 2 (3 veces) y ha vuelto al modo de fase 2 (2 veces compatible). Si después de un breve período de tiempo no ve la mitigación, vuelva a la fase 1 mediante la implementación de su aplicación KCL 3.5.x con la configuración de la fase 1».
-
Acción necesaria: sus empleados estaban trabajando en la fase 2 (3 veces) y la herramienta de migración de KCL los devolvió al modo de fase 2 (2 veces compatible). Si el problema se resuelve, no es necesario volver a realizar la implementación. Si el problema persiste, vuelva a implementar la aplicación KCL 3.5.x con la configuración de la fase 1 () entre sus trabajadores.
CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1
-
