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à.
Rollback a una versione di KCL precedente
Questo argomento spiega come ripristinare l'applicazione consumer KCL 3.5.x+ su KCL 1.x. Il processo di rollback dipende dalla fase di migrazione in cui si trova attualmente l'applicazione.
Torna dalla Fase 1 a KCL 1.x
Se la tua applicazione è in Fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), puoi tornare a KCL 1.x ridistribuendo il codice precedente. La fase 1 è retrocompatibile con KCL 1.x e non crea alcuna voce specifica per la migrazione nella tabella dei leasing. Non è necessario alcuno strumento di migrazione. Per tornare alla Fase 1, ridistribuisci il codice con la tua versione KCL 1.x a tutti i lavoratori.
Importante
La Fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) è una modifica fondamentale per il rollback. Una volta che la domanda è entrata nella Fase 2, nella tabella di leasing vengono scritte le voci non relative al leasing (WORKER_METRIC_STATSeMigration3.0) che non sono retrocompatibili con KCL 1.x. Ciò impedisce in modo permanente il rollback diretto a KCL 1.x. Consigliamo vivamente di inserire la domanda nella Fase 1 per un periodo prolungato per convalidare la stabilità prima di passare alla Fase 2.
Torna dalla Fase 2 alla Fase 1
Se la tua applicazione è in Fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X), devi utilizzare il KCL Migration Tool CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1). Si tratta di un processo in due fasi:
-
Esegui il KCL Migration Tool
sul GitHub sito web. -
Ridistribuisci il codice con la configurazione di Fase 1 (opzionale).
Importante
Non è possibile ripristinare due livelli (dalla Fase 2 alla Fase 1 e poi a KCL 1.x). Il KCL Migration Tool gestisce solo il rollback dalla Fase 2 alla Fase 1. Lo strumento non elimina le voci non relative al leasing dalla tabella dei leasing. Queste voci non sono retrocompatibili con KCL 1.x, motivo per cui non è possibile un rollback a due livelli dalla Fase 2 direttamente a KCL 1.x.
Fase 1: eseguire lo Strumento di migrazione di KCL
Quando devi tornare dalla Fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) alla Fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), esegui il KCL Migration Tool. Lo strumento esegue le seguenti attività:
-
Rimuove il Global Secondary Index (LeaseOwnerToLeaseKeyIndex) dalla tabella di leasing in DynamoDB. Questo indice è stato creato da KCL 3.5.x+ ma non è necessario quando si torna alla Fase 1.
-
Consente a tutti i lavoratori di funzionare in una modalità compatibile con KCL 1.x e di iniziare a utilizzare l’algoritmo di bilanciamento del carico utilizzato nelle versioni precedenti di KCL. Se hai problemi con il nuovo algoritmo di bilanciamento del carico in KCL 3.5.x+, questo mitiga immediatamente il problema.
Importante
La voce relativa allo stato del coordinatore (Migration3.0) nella tabella di leasing non deve essere eliminata durante il processo di migrazione, rollback e rollforward.
Nota
Tutti i lavoratori dell'applicazione consumer devono utilizzare lo stesso algoritmo di bilanciamento del carico in un determinato momento. Il KCL Migration Tool assicura che tutti i lavoratori dell'applicazione consumer KCL 3.5.x+ passino alla modalità compatibile con KCL 1.x in modo che tutti i lavoratori eseguano lo stesso algoritmo di bilanciamento del carico durante la distribuzione successiva alla Fase 1.
Puoi scaricare il KCL Migration Tool nella directory degli scripts del repository KCL.
python3 ./KclMigrationTool.py --regionregion--mode rollback [--application_nameapplicationName] [--lease_table_nameleaseTableName]
Parameters
--region-
Sostituisci
regioncon il tuo. Regione AWS --application_name-
Questo parametro è obbligatorio se si utilizza il nome predefinito per la tabella di leasing. Se è stato specificato un nome personalizzato per la tabella di leasing, è possibile omettere questo parametro. Sostituiscilo
applicationNamecon il nome effettivo dell'applicazione KCL. Lo strumento usa questo nome per derivare il nome predefinito della tabella se non viene fornito un nome personalizzato. --lease_table_name-
Questo parametro è necessario se si imposta un nome personalizzato per la tabella di lease nella configurazione KCL. Se si utilizza il nome della tabella predefinito, è possibile omettere questo parametro. Sostituisci
leaseTableNamecon il nome della tabella personalizzata che hai specificato per la tua tabella di leasing.
Passaggio 2: ridistribuisci il codice con la configurazione di Fase 1 (opzionale)
Dopo aver eseguito il KCL Migration Tool per il rollback dalla Fase 2 alla Fase 1, vedrai uno di questi messaggi:
- Messaggio 1
-
“Rollback completato. La tua applicazione eseguiva la funzionalità di Fase 2 (compatibile 2x). Torna alla Fase 1 implementando la tua applicazione KCL 3.5.x con la configurazione Fase 1.»
Azione richiesta: i tuoi lavoratori funzionavano in modalità compatibile con KCL 1.x (la Fase 2 non era ancora passata automaticamente al bilanciamento completo del carico 3.x). Ridistribuisci la tua applicazione KCL 3.5.x+ con la configurazione di Fase 1 () ai tuoi lavoratori.
CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1 - Messaggio 2
-
“Rollback completato. La tua applicazione KCL eseguiva la funzionalità di Fase 2 (3x) ed è stata ripristinata alla modalità Fase 2 (compatibile 2x). Se non vedi alcuna attenuazione dopo un breve periodo di tempo, torna alla Fase 1 implementando la tua applicazione KCL 3.5.x con la configurazione di Fase 1».
Azione richiesta: i tuoi dipendenti erano passati automaticamente al bilanciamento del carico completo di KCL 3.x e il KCL Migration Tool li ha riportati alla modalità compatibile con KCL 1.x. Se il problema è stato risolto, non è necessario ridistribuirlo. Se il problema persiste, ridistribuisci l'applicazione KCL 3.5.x+ con configurazione di Fase 1 () ai tuoi dipendenti.
CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1
