Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Formato a tabella singola per KCL
A partire da KCL 3.5, puoi consolidare tutti i metadati DynamoDB in un'unica tabella di leasing utilizzando il formato a tabella singola. Per impostazione predefinita, KCL 3.x crea tre tabelle DynamoDB per ogni applicazione: la tabella di lease, la tabella delle metriche dei lavoratori e la tabella dello stato del coordinatore. Il formato a tabella singola riduce queste tre tabelle a una sola, il che aiuta a evitare i limiti delle tabelle a livello di account DynamoDB.
Come funziona il formato a tabella singola
In formato tabella singola, KCL memorizza le metriche dei lavoratori e le voci dello stato del coordinatore nella tabella di leasing insieme alle voci del leasing. Ogni elemento include un entityType attributo che distingue tra i diversi tipi di record.
Le metriche dei lavoratori e gli elementi relativi allo stato del coordinatore utilizzano la stessa struttura di chiavi primarie della tabella di leasing ma includono un valore distinto. entityType Questo attributo consente a KCL di identificare lo scopo di ogni elemento durante le scansioni della tabella.
Ogni componente di KCL filtra le voci necessarie per la sua logica aziendale in base all'attributo. entityType Ad esempio, il Lease Assignment Manager (LAM) filtra le voci relative alle metriche relative al leasing e al lavoratore per eseguire l'assegnazione del leasing.
Configura il formato a tabella singola
Il modo in cui abiliti il formato a tabella singola dipende dalla tua attuale versione di KCL:
-
Se utilizzi KCL 2.x: segui la guida alla migrazione aggiornata per eseguire l'aggiornamento a KCL 3.5. Il formato a tabella singola viene utilizzato per impostazione predefinita per le nuove migrazioni da 2.x a 3.5.
-
Se utilizzi KCL 3.0—3.4: devi eseguire una distribuzione in due fasi per migrare al formato a tabella singola. Vedi i seguenti passaggi di configurazione e migrazione.
Per i clienti esistenti di KCL 3.x, imposta l'opzione di migrateAllEntitiesToLeaseTable configurazione in. CoordinatorConfig Questa opzione controlla se KCL memorizza tutti i tipi di entità di metadati nella tabella di leasing.
| Valore | Default (Predefinito) | Effetto |
|---|---|---|
false |
Sì |
KCL utilizza tabelle separate per le metriche dei lavoratori e lo stato del coordinatore. Il codice dell'applicazione supporta il formato a tabella singola ma non lo attiva. |
true |
No |
KCL inizia a scrivere le metriche dei lavoratori e i dati sullo stato dei coordinatori nella tabella dei contratti di locazione. Imposta questo valore nella fase 2 di implementazione dopo i reach |
La migrazione da KCL 3.x al formato a tabella singola richiede una distribuzione in due fasi:
-
Fase 1: distribuisci il codice KCL 3.5 aggiornato con
migrateAllEntitiesToLeaseTableset to (impostazione predefinita).falseQuesto installa il nuovo codice che supporta il formato a tabella singola ma non attiva la migrazione. -
Fase 2: dopo che tutti i worker hanno eseguito il nuovo codice e
TableMigrationStatusiDEPLOYEDreach e dopo aver verificato che non vi siano regressioni, eseguite nuovamente la distribuzione conmigrateAllEntitiesToLeaseTablesettrueto per iniziare la migrazione.
Stati di migrazione
TableMigrationStateMachineGestisce la transizione dal formato multitabella al formato a tabella singola. KCL tiene traccia dello stato di migrazione corrente in una voce separata dello stato del coordinatore chiamata TableMigration3.5 nella tabella dello stato del coordinatore. Per l'elenco completo di stati, transizioni e descrizioni, consulta gli stati di migrazione a tabella singola di KCL
| Stato | Description | Condizione di transizione |
|---|---|---|
INIT |
Stato iniziale Tutti i lavoratori emettono il codice di supporto minimo nelle statistiche metriche dei lavoratori. I lavoratori continuano a inserire le metriche dei lavoratori nella tabella precedente e a leggere le metriche dei lavoratori e lo stato del coordinatore sia dalla tabella precedente che da quella di leasing. Dal punto di vista funzionale, non c'è differenza tra INIT e DEPLOYED. |
Tutti i lavoratori emettono costantemente il codice di supporto minimo per il tempo di cottura. L'applicazione è pronta per passare alla fase 2 della distribuzione. |
DEPLOYED |
Tutti i lavoratori sono stati impiegati con il nuovo codice (Fase 1 completata). L'applicazione supporta il formato a tabella singola ma non lo ha attivato. |
La fase 2 di distribuzione inizia con |
PENDING |
Tutti i lavoratori eseguono il nuovo codice. KCL migra i dati dalle metriche dei lavoratori e dalle tabelle degli stati dei coordinatori alla tabella delle locazioni. |
Una volta completata la migrazione, trascorre un tempo di cottura predefinito di 24 ore. |
COMPLETE |
La migrazione è completa. KCL utilizza la tabella di lease esclusivamente per tutte le letture e le scritture. Le vecchie metriche dei lavoratori e le tabelle degli stati dei coordinatori non vengono più utilizzate. |
Stato terminale. Non si verificano ulteriori transizioni. |
Per informazioni dettagliate su ogni stato, sulle condizioni di transizione e sul comportamento completo della macchina a stati, consulta KCL Single Table Migration State
Nota
Il tempo di cottura predefinito tra gli stati PENDING e COMPLETE è di 24 ore, ma puoi configurarlo fino a una settimana. Durante questo periodo, KCL utilizza la tabella di lease per tutte le letture e le scritture ma non elimina le vecchie tabelle. È necessario eliminare manualmente le vecchie metriche dei lavoratori e le tabelle degli stati dei coordinatori dopo aver confermato che la migrazione è avvenuta correttamente. KCL non elimina queste tabelle automaticamente.
Considerazioni sul rollback
Il supporto per il rollback dipende dalla versione attuale: TableMigrationStatus
-
Durante la Fase 1 (
TableMigrationStatusèDEPLOYEDo non è ancora impostata): puoi tornare alla versione precedente in tutta sicurezza. Il nuovo codice viene eseguito in una modalità compatibile con le versioni precedenti e nessun dato è stato scritto nelle voci non di lease nella tabella di lease. -
Durante la Fase 2 (
TableMigrationStatusèDEPLOYEDoPENDING): è possibile tornare alla Fase 1. I lavoratori tornano a utilizzare le tabelle precedenti (formato multitavola) per le metriche dei lavoratori e lo stato del coordinatore. La migrazione è stata annullata. -
Dopo lo stato COMPLETE: il rollback non è supportato. KCL utilizza solo la tabella di leasing per tutte le entità. Anche se il codice torna alla Fase 1, il lavoratore continua a utilizzare la tabella di leasing per tutte le entità e la configurazione viene ignorata.
avvertimento
Dopo che la migrazione ha raggiunto lo stato COMPLETE, l'applicazione funziona esclusivamente in modalità a tabella singola. La migrateAllEntitiesToLeaseTable configurazione viene ignorata e KCL non torna a utilizzare tabelle separate. Assicurati che il tempo di cottura prima di passare a COMPLETE sia sufficiente, perché dopo di che anche un rollback del codice non torna a più tabelle.
Best practice
Segui queste best practice quando adotti il formato a tabella singola:
-
Dopo l'implementazione della Fase 1, verifica che l'ingresso dello stato coordinatore
TableMigration3.5raggiungaDEPLOYEDlo stato. Assicuratevi che non vi siano regressioni prima di procedere alla Fase 2. -
Monitora l'ingresso nello stato
TableMigration3.5coordinatore per tenere traccia dei progressiTableMigrationStatusnegli stati DEPLOYED, PENDING e COMPLETE. Lo stato viene memorizzato nella tabella degli stati del coordinatore come voce separata (non nella tabella di leasing) fino a quando la migrazione non raggiunge COMPLETE. -
Assicurati che il tempo di cottura prima di passare a COMPLETE sia sufficiente, perché dopo di che anche un rollback del codice non ritorna a più tabelle. L'applicazione funziona solo in modalità tabella singola.
-
Una volta completata la migrazione, elimina manualmente le vecchie metriche dei lavoratori e le tabelle degli stati dei coordinatori. KCL non elimina queste tabelle automaticamente, ma smette solo di usarle.
-
Se hai configurato
CoordinatorConfig.coordinatorStateTableConfigoLeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig, puoi rimuovere queste configurazioni al termine della migrazione. Queste configurazioni sono obsolete in KCL 3.5 e versioni successive.