Rollback a una versione di KCL precedente - Flusso di dati Amazon Kinesis
Fase 1: eseguire lo Strumento di migrazione di KCL Passaggio 2: ridistribuisci il codice con la versione precedente di KCL (opzionale)

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 i passaggi per ripristinare la versione precedente del consumatore. Quando è necessario eseguire il rollback, è prevista una procedura in due fasi:

  1. Esegui lo Strumento di migrazione di KCL.

  2. Ridistribuisci il codice della versione precedente di KCL (opzionale).

Fase 1: eseguire lo Strumento di migrazione di KCL

Quando è necessario tornare alla versione precedente di KCL, occorre eseguire lo Strumento di migrazione KCL. Il KCL Migration Tool svolge due compiti importanti:

  • Rimuove una tabella di metadati denominata tabella delle metriche dei lavoratori e l’indice secondario globale nella tabella di lease in DynamoDB. Questi due artefatti sono creati da KCL 3.x ma non sono necessari quando si torna alla versione precedente.

  • Consente a tutti i lavoratori di funzionare in una modalità compatibile con KCL 2.x e di iniziare a utilizzare l'algoritmo di bilanciamento del carico utilizzato nelle versioni precedenti di KCL. In caso di problemi con il nuovo algoritmo di bilanciamento del carico in KCL 3.x, questo ridurrà immediatamente il problema.

Importante

La tabella dello stato del coordinatore in DynamoDB deve esistere e non deve essere eliminata durante il processo di migrazione, rollback e rollforward.

Nota

È importante che tutti i lavoratori dell’applicazione consumer utilizzino lo stesso algoritmo di bilanciamento del carico in un determinato momento. Lo strumento di migrazione KCL fa in modo che tutti i lavoratori dell'applicazione consumer KCL 3.x passino alla modalità compatibile con KCL 2.x in modo che tutti i lavoratori eseguano lo stesso algoritmo di bilanciamento del carico durante il roll-depayment alla versione precedente di KCL.

Puoi scaricare lo strumento di migrazione KCL nella directory degli script del repository KCL. GitHub Lo script può essere eseguito da qualsiasi lavoratore o da qualsiasi host che disponga delle autorizzazioni necessarie per scrivere nella tabella degli stati del coordinatore, eliminare la tabella delle metriche dei lavoratori e aggiornare la tabella dei leasing. Puoi fare riferimento all'autorizzazione IAM richiesta Autorizzazioni IAM richieste per le applicazioni consumer KCL per eseguire lo script. È necessario eseguire lo script solo una volta per applicazione KCL. È possibile eseguire lo strumento di migrazione KCL con il seguente comando: 

python3 ./KclMigrationTool.py --region <region> --mode rollback [--application_name <applicationName>] [--lease_table_name <leaseTableName>] [--coordinator_state_table_name <coordinatorStateTableName>] [--worker_metrics_table_name <workerMetricsTableName>]

Parametri

  • --region: sostituisci <region> con il tuo. Regione AWS

  • --application_name: Questo parametro è obbligatorio se utilizzi nomi predefiniti per le tabelle dei metadati di DynamoDB (lease table, coordinator state table e worker metrics table). Se sono stati specificati nomi personalizzati per queste tabelle, è possibile omettere questo parametro. <applicationName>Sostituiscilo con il nome effettivo dell'applicazione KCL. Lo strumento utilizza questo nome per ricavare i nomi delle tabelle predefiniti se non vengono forniti nomi personalizzati.

  • --lease_table_name (opzionale): questo parametro è necessario quando hai impostato un nome personalizzato per la tabella di leasing nella tua configurazione KCL. Se si utilizza il nome della tabella predefinito, è possibile omettere questo parametro. Sostituiscilo leaseTableName con il nome della tabella personalizzata che hai specificato per la tua tabella di leasing.

  • --coordinator_state_table_name (opzionale): questo parametro è necessario quando hai impostato un nome personalizzato per la tabella degli stati del coordinatore nella tua configurazione KCL. Se si utilizza il nome della tabella predefinito, è possibile omettere questo parametro. Sostituisci <coordinatorStateTableName> con il nome della tabella personalizzata che hai specificato per la tabella degli stati del coordinatore.

  • --worker_metrics_table_name (opzionale): questo parametro è necessario quando hai impostato un nome personalizzato per la tabella delle metriche dei lavoratori nella tua configurazione KCL. Se si utilizza il nome della tabella predefinito, è possibile omettere questo parametro. Sostituiscilo con il nome <workerMetricsTableName> della tabella personalizzata che hai specificato per la tabella delle metriche dei lavoratori.

Passaggio 2: ridistribuisci il codice con la versione precedente di KCL (opzionale)

Dopo aver eseguito lo strumento di migrazione di KCL per un rollback, verrà mostrato uno di questi messaggi:

  • Messaggio 1: «Rollback completato. L'applicazione KCL eseguiva la modalità compatibile con KCL 2.x. Se non vedi alcuna mitigazione di alcuna regressione, torna ai file binari dell'applicazione precedente distribuendo il codice con la versione KCL precedente.»

    • Azione richiesta: Ciò significa che i tuoi lavoratori funzionavano nella modalità compatibile con KCL 2.x. Se il problema persiste, ridistribuisci il codice con la versione precedente di KCL ai tuoi lavoratori.

  • Messaggio 2: «Rollback completato. L'applicazione KCL eseguiva la modalità di funzionalità KCL 3.x. Il rollback ai file binari dell'applicazione precedente non è necessario, a meno che non si veda alcuna mitigazione del problema entro 5 minuti. Se il problema persiste, ripristina i file binari dell'applicazione precedente distribuendo il codice con la versione precedente di KCL.»

    • Azione richiesta: Ciò significa che i tuoi lavoratori lavoravano in modalità KCL 3.x e lo strumento di migrazione KCL ha portato tutti i lavoratori alla modalità compatibile con KCL 2.x. Se il problema viene risolto, non è necessario ridistribuire il codice con la versione precedente di KCL. Se il problema persiste, ridistribuisci il codice con la versione precedente di KCL ai tuoi worker.