本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
回滚到之前的KCL版本
本主题说明了将使用器回滚到先前版本的步骤。当你需要回滚时，有两个步骤的过程：
-
运行KCL迁移工具
。 -
重新部署先前KCL版本的代码（可选）。
步骤 1：运行KCL迁移工具
当需要回滚到以前的KCL版本时，必须运行KCL迁移工具。KCL迁移工具执行两项重要任务：
-
它会在 DynamoDB 的租用表上删除一个名为工作器指标表的元数据表和全局二级索引。这两个构件由 KCL 3.x 创建，但在回滚到先前版本时并不需要。
它使所有工作程序都以与 KCL 2.x 兼容的模式运行，并开始使用先前KCL版本中使用的负载平衡算法。如果您在使用 KCL 3.x 中的新负载平衡算法时遇到问题，这将立即缓解问题。
重要
DynamoDB 中的协调器状态表必须存在，并且在迁移、回滚和前滚过程中不得删除。
注意
在给定时间使用者应用程序中的所有工作程序都必须使用相同的负载平衡算法，这一点很重要。KCL迁移工具可确保您的 KCL 3.x 消费者应用程序中的所有工作人员都切换到 KCL 2.x 兼容模式，以便在将还款回滚到之前版本的过程中，所有工作人员都运行相同的负载平衡算法。KCL
可以在KCL GitHub存储库
python3 ./KclMigrationTool.py --region <region> --mode rollback [--application_name <applicationName>] [--lease_table_name <leaseTableName>] [--coordinator_state_table_name <coordinatorStateTableName>] [--worker_metrics_table_name <workerMetricsTableName>]
参数
-
--region：
<region>替换为你的。 AWS 区域 -
--application_name：如果您为 DynamoDB 元数据表（租赁表、协调器状态表和工作人员指标表）使用默认名称，则此参数为必填项。如果您为这些表指定了自定义名称，则可以省略此参数。
<applicationName>替换为实际的KCL应用程序名称。如果未提供自定义名称，则该工具将使用此名称派生默认表名。 -
--lease_table_name（可选）：当您在配置中为租赁表设置了自定义名称时，需要此参数。KCL如果您使用的是默认表名，则可以省略此参数。
leaseTableName替换为您为租用表指定的自定义表名。 -
--coderator_state_table_name（可选）：当您在配置中为协调器状态表设置了自定义名称时，需要此参数。KCL如果您使用的是默认表名，则可以省略此参数。
<coordinatorStateTableName>替换为您为协调器状态表指定的自定义表名。 -
--worker_metrics_table_name（可选）：当您在配置中为工作人员指标表设置了自定义名称时，需要此参数。KCL如果您使用的是默认表名，则可以省略此参数。
<workerMetricsTableName>替换为您为工作人员指标表指定的自定义表名。
步骤 2：使用先前KCL版本重新部署代码（可选）
运行KCL迁移工具进行回滚后，您将看到以下一条消息：
-
消息 1：“回滚已完成。您的KCL应用程序正在运行 KCL 2.x 兼容模式。如果您看不到任何回归的缓解措施，请使用先前KCL版本部署代码，回滚到之前的应用程序二进制文件。”
-
必需的操作：这意味着您的工作人员正在 KCL 2.x 兼容模式下运行。如果问题仍然存在，请将具有先前KCL版本的代码重新部署给您的工作人员。
-
-
消息 2：“回滚已完成。您的KCL应用程序正在运行 KCL 3.x 功能模式。除非您在 5 分钟内看不到该问题的缓解措施，否则无需回滚到以前的应用程序二进制文件。如果仍有问题，请使用先前KCL版本部署代码，回滚到以前的应用程序二进制文件。”
-
必需的操作：这意味着您的工作人员在 KCL 3.x 模式下运行，并且KCL迁移工具已将所有工作人员切换到兼容 KCL 2.x 的模式。如果问题得到解决，则无需使用先前KCL版本重新部署代码。如果问题仍然存在，请将具有先前KCL版本的代码重新部署给您的工作人员。
-
