

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 versão anterior da KCL
<a name="kcl-migration-rollback"></a>

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

1. Execute a [Ferramenta de Migração da KCL](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py).

1. Reimplantar o código da versão anterior da KCL (opcional).

## Etapa 1: executar a Ferramenta de Migração da KCL
<a name="kcl-migration-rollback-tool"></a>

Quando precisar reverter para a versão anterior da KCL, você deve executar a Ferramenta de Migração da KCL. A Ferramenta de migração da KCL executa duas tarefas importantes:
+ Ela remove uma tabela de metadados chamada tabela de métricas do operador e o índice secundário global na tabela de concessões no DynamoDB. Esses dois artefatos são criados pela KCL 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 o KCL 2.x e comecem a usar o algoritmo de balanceamento de carga usado nas versões anteriores do KCL. Se você tiver problemas com o novo algoritmo de balanceamento de carga na KCL 3.x, isso mitigará 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 avanço. 

**nota**  
É importante que todos os operadores em sua aplicação de consumidor usem o mesmo algoritmo de balanceamento de carga em um determinado momento. A Ferramenta de migração da KCL garante que todos os operadores em sua aplicação de consumo da KCL 3.x mudem para o modo compatível com a KCL 2.x para que todos os operadores executem o mesmo algoritmo de balanceamento de carga durante a reversão da aplicação para a versão anterior da KCL.

Você pode baixar a [Ferramenta de Migração KCL](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py) no diretório de scripts do repositório [KCL GitHub](https://github.com/awslabs/amazon-kinesis-client/tree/master). O script pode ser executado em qualquer operador ou em qualquer host que tenha as permissões necessárias para gravar na tabela de estados do coordenador, excluir a tabela de métricas do operador e atualizar a tabela de concessões. Consulte [Permissões do IAM necessárias para aplicativos de consumo da KCL](kcl-iam-permissions.md) para obter a permissão necessária do IAM para executar o script. É necessário executar o script uma única vez para cada aplicação da KCL. É possível executar a Ferramenta de migração da KCL 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\$1name: esse parâmetro é obrigatório se você estiver usando nomes padrão para suas tabelas de metadados do DynamoDB (tabela de concessões, tabela de estados do coordenador e tabela de métricas do operador). Se você tiver especificado nomes personalizados para essas tabelas, poderá omitir esse parâmetro. Substitua `<applicationName>` pelo nome real da aplicação da KCL. A ferramenta usa esse nome para obter os nomes de tabela padrão se os nomes personalizados não forem fornecidos.
+ --lease\$1table\$1name (opcional): esse parâmetro é necessário quando você define um nome personalizado para a tabela de concessões na configuração da KCL. Se você estiver usando o nome padrão da tabela, poderá omitir esse parâmetro. Substitua `leaseTableName` pelo nome da tabela personalizada que você especificou para a tabela de concessões.
+ --coordinator\$1state\$1table\$1name (opcional): esse parâmetro é necessário quando você define um nome personalizado para a tabela de estados do coordenador na configuração da KCL. Se você estiver usando o nome padrão da tabela, poderá omitir esse parâmetro. Substitua `<coordinatorStateTableName>` pelo nome da tabela personalizada que você especificou para a tabela de estados do coordenador. 
+ --worker\$1metrics\$1table\$1name (opcional): esse parâmetro é necessário quando você define um nome personalizado para a tabela de métricas do operador na configuração da KCL. Se você estiver usando o nome padrão da tabela, poderá omitir esse parâmetro. Substitua `<workerMetricsTableName>` pelo nome da tabela personalizada que você especificou para a tabela de métricas do operador. 

## Etapa 2: reimplantar o código com a versão anterior da KCL (opcional)
<a name="kcl-migration-rollback-redeploy"></a>

 Depois de executar a Ferramenta de Migração da KCL para uma reversão, você verá uma destas mensagens:
+ **Mensagem 1:** “Reversão concluída. Sua aplicação da KCL estava executando o modo compatível com KCL 2.x. Se não houver mitigação de nenhuma regressão, reverta para os binários anteriores da aplicação implantando o código com sua versão anterior da 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 versão anterior da KCL para seus operadores.
+ **Mensagem 2: **“Reversão concluída. Sua aplicação da KCL estava executando o modo de funcionalidade da KCL 3.x. A reversão para os binários anteriores da aplicação não é necessária, a menos que você não veja nenhuma mitigação do problema em 5 minutos. Se o problema persistir, reverta para os binários anteriores da aplicação implantando o código com sua versão anterior da KCL.”
  + **Ação necessária:** Isso significa que seus trabalhadores estavam executando no modo KCL 3.x e a Ferramenta de Migração KCL mudou todos os trabalhadores para o modo compatível com KCL 2.x. Se o problema for resolvido, você não precisa reimplantar o código com a versão anterior da KCL. Se o problema persistir, reimplante o código com a versão anterior da KCL para seus operadores.

 