Reverter para a KCL versão anterior - Amazon Kinesis Data Streams
Etapa 1: Executar a ferramenta de KCL migração Etapa 2: reimplantar o código com a KCL versão anterior (opcional)

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Reverter para a KCL versão anterior

Este tópico explica as etapas para reverter seu consumidor para a versão anterior. Quando você precisa reverter, há um processo de duas etapas:

  1. Execute a ferramenta de KCL migração.

  2. Reimplante o código da KCL versão anterior (opcional).

Etapa 1: Executar a ferramenta de KCL migração

Quando precisar voltar para a KCL versão anterior, você deve executar a Ferramenta de KCL Migração. A Ferramenta de KCL Migração executa duas tarefas importantes:

  • Ele remove uma tabela de metadados chamada tabela de métricas do trabalhador e índice secundário global na tabela de lease no DynamoDB. Esses dois artefatos são criados pela KCL versão 3.x, mas não são necessários quando você reverte para a versão anterior.

  • Isso faz com que todos os trabalhadores funcionem em um modo compatível com KCL 2.x e comecem a usar o algoritmo de balanceamento de carga usado nas versões anterioresKCL. Se você tiver problemas com o novo algoritmo de balanceamento de carga na KCL versão 3.x, isso atenuará o problema imediatamente.

Importante

A tabela de estados do coordenador no DynamoDB deve existir e não deve ser excluída durante o processo de migração, reversão e reversão.

nota

É importante que todos os trabalhadores em seu aplicativo de consumo usem o mesmo algoritmo de balanceamento de carga em um determinado momento. A Ferramenta de KCL Migração garante que todos os funcionários em seu aplicativo de consumidor KCL 3.x mudem para o modo compatível com KCL 2.x para que todos os funcionários executem o mesmo algoritmo de balanceamento de carga durante a reversão do reembolso para a versão anterior. KCL

Você pode baixar a Ferramenta de KCL Migração no diretório de scripts do KCL GitHubrepositório. O script pode ser executado a partir de qualquer um dos seus trabalhadores ou de qualquer host que tenha as permissões necessárias para gravar na tabela de estado do coordenador, excluir a tabela de métricas do trabalhador e atualizar a tabela de locação. Você pode consultar IAMpermissões necessárias para aplicativos de KCL consumo para obter a IAM permissão necessária para executar o script. Você deve executar o script somente uma vez por KCL aplicativo. Você pode executar a Ferramenta de KCL Migração com o seguinte 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>]

Parâmetros

  • --region: substitua <region> por sua. Região da AWS

  • --application_name: esse parâmetro é obrigatório se você estiver usando nomes padrão para suas tabelas de metadados do DynamoDB (tabela de lease, tabela de estado do coordenador e tabela de métricas de trabalhadores). Se você tiver especificado nomes personalizados para essas tabelas, poderá omitir esse parâmetro. <applicationName>Substitua pelo nome real do KCL aplicativo. A ferramenta usa esse nome para derivar os nomes de tabela padrão se os nomes personalizados não forem fornecidos.

  • --lease_table_name (opcional): Esse parâmetro é necessário quando você define um nome personalizado para a tabela de concessão em sua configuração. KCL Se você estiver usando o nome da tabela padrão, poderá omitir esse parâmetro. leaseTableNameSubstitua pelo nome da tabela personalizada que você especificou para sua tabela de leasing.

  • --coordinator_state_table_name (opcional): Esse parâmetro é necessário quando você define um nome personalizado para a tabela de estados do coordenador em sua configuração. KCL Se você estiver usando o nome da tabela padrão, poderá omitir esse parâmetro. <coordinatorStateTableName>Substitua pelo nome da tabela personalizada que você especificou para a tabela de estados do coordenador.

  • --worker_metrics_table_name (opcional): esse parâmetro é necessário quando você define um nome personalizado para a tabela de métricas do trabalhador em sua configuração. KCL Se você estiver usando o nome da tabela padrão, poderá omitir esse parâmetro. <workerMetricsTableName>Substitua pelo nome da tabela personalizada que você especificou para a tabela de métricas do trabalhador.

Etapa 2: reimplantar o código com a KCL versão anterior (opcional)

Depois de executar a Ferramenta de KCL Migração para uma reversão, você verá uma das seguintes mensagens:

  • Mensagem 1: “Reversão concluída. Seu KCL aplicativo estava executando o modo compatível com KCL 2.x. Se você não vê a mitigação de nenhuma regressão, reverta para os binários anteriores do aplicativo implantando o código com sua versão anterior.” KCL

    • Ação necessária: isso significa que seus trabalhadores estavam executando no modo compatível com KCL 2.x. Se o problema persistir, reimplante o código com a KCL versão anterior para seus trabalhadores.

  • Mensagem 2: “Reversão concluída. Seu KCL aplicativo estava executando o modo de funcionalidade KCL 3.x. A reversão para os binários anteriores do aplicativo não é necessária, a menos que você não veja nenhuma mitigação para o problema em 5 minutos. Se você ainda tiver um problema, reverta para os binários anteriores do aplicativo implantando o código com a versão anterior.” KCL

    • Ação necessária: Isso significa que seus trabalhadores estavam executando no modo KCL 3.x e a Ferramenta de KCL Migração mudou todos os trabalhadores para o modo compatível com KCL 2.x. Se o problema for resolvido, você não precisará reimplantar o código com a KCL versão anterior. Se o problema persistir, reimplante o código com a KCL versão anterior para seus trabalhadores.