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.
Formato de tabla única para KCL
A partir de KCL 3.5, puede consolidar todos los metadatos de DynamoDB en una sola tabla de arrendamiento con el formato de tabla única. De forma predeterminada, KCL 3.x crea tres tablas de DynamoDB para cada aplicación: la tabla de arrendamientos, la tabla de métricas de los trabajadores y la tabla de estados de los coordinadores. El formato de tabla única reduce estas tres tablas a una, lo que ayuda a evitar los límites de tablas a nivel de cuenta de DynamoDB.
Cómo funciona el formato de tabla única
En formato de tabla única, KCL almacena las métricas de los trabajadores y las entradas del estado del coordinador en la tabla de arrendamientos junto con las entradas de arrendamiento. Cada elemento incluye un entityType atributo que distingue entre los distintos tipos de registro.
Las métricas de los trabajadores y el estado del coordinador utilizan la misma estructura de clave principal que la tabla de arrendamientos, pero incluyen un entityType valor distinto. Este atributo permite a KCL identificar el propósito de cada elemento durante el escaneo de la tabla.
Cada componente de KCL filtra las entradas que necesita para su lógica empresarial en función del entityType atributo. Por ejemplo, el administrador de asignaciones de arrendamientos (LAM) filtra las entradas de métricas de arrendamientos y trabajadores para realizar la asignación de arrendamientos.
Configure el formato de tabla única
La forma de habilitar el formato de tabla única depende de la versión actual de KCL:
-
Si utiliza KCL 2.x: siga la guía de migración actualizada para actualizar a KCL 3.5. El formato de tabla única se utiliza de forma predeterminada para las nuevas migraciones de la versión 2.x a la 3.5.
-
Si utiliza KCL 3.0—3.4: debe realizar un despliegue en dos fases para migrar al formato de tabla única. Consulte los siguientes pasos de configuración y migración.
Para los clientes actuales de KCL 3.x, defina la opción de migrateAllEntitiesToLeaseTable configuración en. CoordinatorConfig Esta opción controla si KCL almacena todos los tipos de entidades de metadatos en la tabla de arrendamiento.
| Valor | Predeterminado | Efecto |
|---|---|---|
false |
Sí |
KCL utiliza tablas independientes para las métricas de los trabajadores y el estado del coordinador. El código de la aplicación admite el formato de tabla única, pero no lo activa. |
true |
No |
KCL comienza a incluir las estadísticas de los trabajadores y los datos del estado del coordinador en la tabla de arrendamientos. Establezca este valor en el despliegue de la fase 2 después de los |
La migración de KCL 3.x a un formato de tabla única requiere una implementación en dos fases:
-
Fase 1: Implemente el código KCL 3.5 actualizado con el valor
migrateAllEntitiesToLeaseTablepredeterminado.falseEsto instala el nuevo código que admite el formato de tabla única, pero no activa la migración. -
Fase 2: Una vez que todos los trabajadores ejecuten el nuevo código y los
TableMigrationStatusalcancesDEPLOYED, y de que hayas comprobado que no hay regresiones, vuelve a desplegarlo con el comandomigrateAllEntitiesToLeaseTablesettrueto para iniciar la migración.
Estados de migración
TableMigrationStateMachineGestiona la transición del formato de varias tablas al formato de una sola tabla. La KCL rastrea el estado actual de la migración en una entrada independiente de estados coordinadores llamada TableMigration3.5 en la tabla de estados coordinadores. Para ver la lista completa de estados, transiciones y descripciones, consulte los estados de migración de una sola tabla de la KCL
| Estado | Description (Descripción) | Condición de transición |
|---|---|---|
INIT |
Estado inicial. Todos los trabajadores emiten el código de apoyo mínimo en las estadísticas métricas de los trabajadores. Los trabajadores siguen introduciendo las métricas de los trabajadores en la tabla anterior y leyendo las métricas de los trabajadores y el estado del coordinador tanto en las tablas antiguas como en las de arrendamiento. Desde el punto de vista funcional, no hay diferencia entre INIT y DEPLOYED. |
Todos los trabajadores emiten el código de soporte mínimo de forma constante durante el horneado. La aplicación está lista para pasar a la fase 2 de despliegue. |
DEPLOYED |
Se ha desplegado a todos los trabajadores con el nuevo código (se ha completado la fase 1). La aplicación admite el formato de tabla única, pero no lo ha activado. |
El despliegue de la fase 2 comienza con la |
PENDING |
Todos los trabajadores ejecutan el nuevo código. KCL migra los datos de las tablas de métricas de los trabajadores y estados de los coordinadores a la tabla de arrendamientos. |
Una vez finalizada la migración, transcurre un tiempo de espera predeterminado de 24 horas. |
COMPLETE |
La migración ha finalizado. KCL utiliza la tabla de arrendamiento exclusivamente para todas las lecturas y escrituras. Las antiguas tablas de métricas de los trabajadores y estados de los coordinadores ya no se utilizan. |
Estado terminal. No se producen más transiciones. |
Para obtener información detallada sobre cada estado, las condiciones de transición y el comportamiento completo de la máquina de estados, consulte la máquina de estados de migración de tabla única KCL
nota
El tiempo de cocción predeterminado entre los estados PENDIENTE y COMPLETO es de 24 horas, pero puede configurarlo hasta una semana. Durante este período, KCL utiliza la tabla de arrendamiento para todas las lecturas y escrituras, pero no elimina las tablas antiguas. Debe eliminar manualmente las tablas antiguas de métricas de los trabajadores y estados de los coordinadores después de confirmar que la migración se ha realizado correctamente. KCL no elimina estas tablas automáticamente.
Consideraciones de restauración
La compatibilidad con la reversión depende de la corriente: TableMigrationStatus
-
Durante la fase 1 (
TableMigrationStatusestáDEPLOYEDo no está configurada): puede volver a la versión anterior de forma segura. El nuevo código se ejecuta en un modo compatible con versiones anteriores y no se ha escrito ningún dato en las entradas de la tabla de arrendamientos que no sean de arrendamiento. -
Durante la fase 2 (
TableMigrationStatusesDEPLOYEDoPENDING): puedes volver a la fase 1. Los trabajadores vuelven a utilizar las tablas antiguas (formato de varias tablas) para medir las estadísticas de los trabajadores y determinar el estado de los coordinadores. La migración se ha deshecho. -
Tras el estado COMPLETO: no se admite la reversión. KCL solo usa la tabla de arrendamientos para todas las entidades. Incluso si el código vuelve a la fase 1, el trabajador sigue utilizando la tabla de arrendamiento para todas las entidades y se ignora la configuración.
aviso
Una vez que la migración alcanza el estado COMPLETA, la aplicación funciona exclusivamente en el modo de tabla única. La migrateAllEntitiesToLeaseTable configuración se ignora y KCL no vuelve a utilizar tablas independientes. Asegúrese de que el tiempo de horneado antes de pasar a COMPLETADO sea suficiente, ya que después de eso, ni siquiera una reversión de código volverá a tener varias tablas.
Prácticas recomendadas
Siga estas prácticas recomendadas cuando adopte el formato de tabla única:
-
Tras la fase 1 del despliegue, compruebe que la entrada del estado coordinador
TableMigration3.5alcanceDEPLOYEDel estado. Asegúrese de que no haya regresiones antes de pasar a la fase 2. -
Supervise la entrada
TableMigrationStatusen el estadoTableMigration3.5coordinador para hacer un seguimiento del progreso en los estados DESPLEGADO, PENDIENTE y COMPLETO. El estado se almacena en la tabla de estados del coordinador como una entrada independiente (no en la tabla de arrendamientos) hasta que la migración se complete. -
Asegúrese de que el tiempo de horneado antes de pasar a FINALIZAR sea suficiente, ya que después de eso, ni siquiera una reversión de código volverá a tener varias tablas. La aplicación solo funciona en el modo de tabla única.
-
Cuando se complete la migración, elimine manualmente las tablas antiguas de métricas de los trabajadores y estados de los coordinadores. KCL no elimina estas tablas automáticamente, solo deja de usarlas.
-
Si ha configurado
CoordinatorConfig.coordinatorStateTableConfigoLeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig, puede eliminar estas configuraciones una vez finalizada la migración. Estas configuraciones están en desuso en KCL 3.5 y versiones posteriores.
