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 arrendamiento, 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 el formato de tabla única, KCL almacena las estadísticas de los trabajadores y las entradas por estado de los coordinadores en la tabla de arrendamiento junto con las entradas de arrendamiento. Cada elemento incluye un entityType atributo que distingue entre los diferentes tipos de registros.
Las métricas de los trabajadores y los elementos del estado del coordinador utilizan la misma estructura de claves principales que la tabla de arrendamiento, pero incluyen un entityType valor distinto. Este atributo permite a KCL identificar el propósito de cada artículo durante los escaneos 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 asignación de arrendamientos (LAM) filtra las entradas de las métricas de arrendamiento y de trabajadores para realizar la asignación del arrendamiento.
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 usa 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 una implementación 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 usa 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 escribir las métricas de los trabajadores y los datos sobre el estado de los coordinadores en la tabla de arrendamientos. Establezca este valor en la fase 2 de la implementación, una vez |
La migración de KCL 3.x al formato de tabla única requiere una implementación en dos fases:
-
Fase 1: Implemente el código KCL 3.5 actualizado con el valor
migrateAllEntitiesToLeaseTableestablecido en (valor predeterminado).falseEsto instala el nuevo código que admite el formato de tabla única, pero no activa la migración. -
Fase 2: Cuando todos los trabajadores hayan ejecutado el nuevo código y lo hayan
TableMigrationStatusalcanzadoDEPLOYED, y que hayas comprobado que no hay regresiones, vuelve a implementarlo con el valormigrateAllEntitiesToLeaseTableestablecido entruepara iniciar la migración.
Estados de migración
TableMigrationStateMachineGestiona la transición del formato de tablas múltiples al formato de tabla única. La KCL rastrea el estado actual de la migración en una entrada independiente sobre los estados del coordinador denominada TableMigration3.5 en la tabla de estados del coordinador. Para obtener la lista completa de estados, transiciones y descripciones, consulte los estados de migración de una sola tabla de KCL.
| Estado | Description (Descripción) | Condición de transición |
|---|---|---|
INIT |
Estado inicial. Todos los trabajadores emiten el código de soporte mínimo en las estadísticas métricas de los trabajadores. Los trabajadores siguen enviando las métricas de los trabajadores a la tabla anterior y leyendo las métricas de los trabajadores y el estado de los coordinadores 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 manera constante durante el tiempo que dura la cocción. La aplicación está lista para pasar a la fase 2 de implementación. |
DEPLOYED |
Todos los trabajadores han sido desplegados 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. |
La implementación de la fase 2 comienza con la |
PENDING |
Todos los trabajadores ejecutan el nuevo código. KCL migra los datos de las tablas de estados de los coordinadores y métricas de los trabajadores 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 usa la tabla de arrendamiento exclusivamente para todas las lecturas y escrituras. Las antiguas tablas de estados de coordinadores y métricas de los trabajadores 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 de
nota
El tiempo de horneado predeterminado entre los estados PENDIENTE y COMPLETO es de 24 horas, pero puede configurarlo hasta una semana. Durante este período, KCL usa la tabla de arrendamiento para todas las lecturas y escrituras, pero no elimina las tablas antiguas. Debe eliminar manualmente las tablas antiguas de estados de coordinadores y métricas de los trabajadores después de confirmar que la migración se ha realizado correctamente. KCL no elimina estas tablas automáticamente.
Métricas de migración
Con KCL, puede supervisar el progreso y el estado de la migración de una sola tabla mediante CloudWatch métricas. Usa estas métricas para confirmar que los trabajadores han adoptado el nuevo código y para hacer un seguimiento de la migración a medida que avanza en sus estados. También puede detectar errores de lectura, escritura o eliminación de DynamoDB durante la migración. Las tablas siguientes agrupan las métricas según la operación de KCL (dimensión métrica) que las emite y según el momento en que se emite cada métrica.
El trabajador líder elegido emite continuamente las siguientes métricas, independientemente de si hay una migración en curso:
Operación |
Métrica |
Unidad |
Description (Descripción) |
|---|---|---|---|
|
|
Ninguno |
Ordinal del estado actual de la migración a DynamoDB: |
|
|
Ninguno |
Código de soporte mínimo para todos los trabajadores arrendados de la flota. |
El trabajador líder elegido emite las siguientes métricas solo mientras la migración está en curso:
Operación |
Métrica |
Unidad |
Description (Descripción) |
|---|---|---|---|
|
|
Recuento |
Número de trabajadores que admiten trabajar con una sola tabla de DynamoDB, pero que aún no han migrado para usar esa tabla única. |
|
|
Recuento |
Número de trabajadores que han pasado a escribir en la tabla única. Es posible que estos trabajadores sigan leyendo varias tablas hasta que finalice la migración de las tablas. |
|
|
Recuento |
Número de trabajadores de una versión anterior a la 3.5 que no admiten el funcionamiento en una sola tabla de DynamoDB. |
|
|
Recuento |
|
|
|
Recuento |
|
|
|
Recuento |
|
|
|
Recuento |
|
|
|
Milisegundos |
Duración de la operación de movimiento asíncrono. |
|
|
Recuento |
Número de lotes que se movieron correctamente. |
Todos los trabajadores emiten las siguientes métricas mientras la migración está en curso:
Operación |
Métrica |
Unidad |
Description (Descripción) |
|---|---|---|---|
|
|
Recuento |
|
|
|
Milisegundos |
Duración de la ejecución de la máquina de estado. |
|
|
Recuento |
|
|
|
Milisegundos |
Duración de la operación de inicialización. |
Utilice estas métricas para decidir cuándo avanzar en la migración. Cuando StatusOrdinal es consistente 2 (IMPLEMENTADO) y cuándo lo PrePhase1Worker es0, todos los trabajadores admiten el formato de tabla única, y puedes pasar a la fase 2 del despliegue de la migración en tablas. Cuando StatusOrdinal llegue a 4 (COMPLETADO), podrás eliminar de forma segura las tablas antiguas.
Consideraciones de restauración
La compatibilidad con la reversión depende de la situación actualTableMigrationStatus:
-
Durante la fase 1 (
TableMigrationStatusestá configuradaDEPLOYEDo no): 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 son de arrendamiento. -
Durante la fase 2 (
TableMigrationStatusesDEPLOYEDoPENDING): puede volver a la fase 1. Los trabajadores vuelven a usar las tablas antiguas (formato de tablas múltiples) para obtener las métricas de los trabajadores y 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 continúa usando la tabla de arrendamiento para todas las entidades y se ignora la configuración.
aviso
Una vez que la migración alcanza el estado COMPLETO, la aplicación funciona exclusivamente en 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 cocción antes de pasar a COMPLETE sea suficiente, ya que una vez hecho esto, incluso si se revierte el código, no se devuelve a varias tablas.
Prácticas recomendadas
Siga estas prácticas recomendadas cuando adopte el formato de tabla única:
-
Tras la implementación de la fase 1, verifique que la entrada del estado coordinador
TableMigration3.5alcanceDEPLOYEDel estatus. Asegúrese de que no haya regresiones antes de pasar a la fase 2. -
Supervise
TableMigrationStatusla entrada del 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 concesiones) hasta que la migración finalice. -
Asegúrese de que el tiempo de cocción antes de pasar a COMPLETE sea suficiente, ya que una vez hecho esto, incluso si se revierte el código, no se devuelve a varias tablas. La aplicación solo funciona en el modo de tabla única.
-
Una vez finalizada la migración, elimine manualmente las tablas antiguas de estados de coordinadores y métricas de los trabajadores. 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 obsoletas en KCL 3.5 y versiones posteriores.
