--- title: 将 etcd 从 v3.7 降级到 v3.6 weight: 6600 description: 降级 etcd 3.7 至 3.6 的流程、检查清单与注意事项 categories: [任务] upstream_link: "https://github.com/etcd-io/website/blob/824597935df6e95992ef61c07e3222f4f796ca6c/content/en/docs/v3.7/downgrades/downgrade_3_7.md" aliases: [/etcd/downgrades/downgrade_3_7/] --- 在一般情况下,从 etcd v3.7 降级到 v3.6 可以实现零停机、滚动降级: - 逐一停止 etcd v3.7 进程,并替换为 etcd v3.6 进程 - 启用降级后,集群将不再支持 v3.7 中的新特性 开始 [降级](#downgrade-procedure)前,请阅读本指南其余内容并做好准备。 ### 降级检查列表 {#downgrade-checklists} v3.7 与 v3.6 之间的主要差异: #### 不同标志 {#difference-in-flags} v3.7 未引入任何新标志,因此 v3.6 进程可接受 v3.7 配置中的所有标志,降级时无需进行配置更改。 > [!NOTE] > 本次差异对比基于版本 v3.7.0-rc.0 与 v3.6.13。实际差异取决于所用补丁版本,请先查阅 `diff <(etcd-3.7/bin/etcd -h | grep \\-\\-) <(etcd-3.6/bin/etcd -h | grep \\-\\-)`。 在 v3.7 中已弃用的 `--experimental-*` 标志在 v3.6 中仍存在,但降级后不得重新添加;应使用其非实验性等效标志或 `--feature-gates` 条目,两者在两个版本中均有效。 #### Prometheus 指标差异 {#difference-in-prometheus-metrics} ```diff # metrics not available in v3.6 -etcd_server_request_duration_seconds -etcd_debugging_server_watch_send_loop_control_stream_duration_seconds -etcd_debugging_server_watch_send_loop_progress_duration_seconds -etcd_debugging_server_watch_send_loop_watch_stream_duration_seconds -etcd_debugging_server_watch_send_loop_watch_stream_duration_per_event_seconds ``` ### 服务器降级检查清单 {#server-downgrade-checklists} #### 降级要求 {#downgrade-requirements} 为确保平滑的滚动降级,运行中的集群必须处于健康状态。在继续操作前,请使用 `etcdctl endpoint health` 命令检查集群健康状况。 #### 准备 {#preparation} 在将 etcd 降级之前,务必在预发环境中测试依赖 etcd 的服务,确认无误后再将降级操作部署到生产环境。 在开始之前,[下载快照备份](/zh/docs/etcd/op-guide/maintenance/#snapshot-backup)。若降级过程中出现异常,可使用此备份对 [回滚](#rollback)至现有 etcd 版本。 在开始之前,请下载 etcd v3.6 的最新版本。 #### 混合版本 {#mixed-versions} 降级过程中,etcd 集群支持不同版本的 etcd 成员共存,并以最低公共版本的协议运行。当通过 `etcdctl downgrade enable 3.6` 启用降级后,集群即被视为已降级。内部上,集群整体版本被设置为降级目标版本,该版本控制报告的版本号以及所支持的功能。 #### 回滚 {#rollback} 在降级 etcd 集群之前,请创建并 [下载快照备份](/zh/docs/etcd/op-guide/maintenance/#snapshot-backup)。如需恢复集群至降级前的状态,可使用该快照。若用户在降级过程中遇到问题,应首先识别并解决根本原因。 如果降级操作在执行 `etcdctl downgrade enable` 之后开始,且集群仍处于混合版本状态(即至少有一个成员仍运行在 v3.7 版本),用户可以通过执行 `etcdctl downgrade cancel` 取消正在进行的降级过程,并使用原始的 v3.7 二进制文件重启所有已降级的成员。 当所有成员均降级至 v3.6 版本后,集群即被视为已完全降级。若用户在完成完全降级后希望恢复至原始版本,应遵循官方 [升级指南](/zh/docs/etcd/upgrades/upgrade_3_7/),以确保一致性并避免数据损坏。 ### 降级操作 {#downgrade-procedure} 本示例演示如何将运行在本地机器上的 3 个成员 v3.7 etcd 集群降级。以下输出来自在单个主机上使用三个环回端口,对 v3.7.0-rc.0 和 v3.6.13 版本的 etcd 执行的实际运行,该集群在不久之前从 v3.6.13 升级而来。 #### 步骤 1: 检查降级要求 {#step-1-check-downgrade-requirements} 集群是否健康且运行 v3.7.x 版本? ```bash etcdctl --endpoints=localhost:2379,localhost:22379,localhost:32379 endpoint health < [!NOTE] > 启用降级后,即使所有服务器仍在运行 v3.7 二进制文件,集群仍将继续使用 v3.6 协议运行,除非使用 `etcdctl downgrade cancel` 取消降级。 #### 第 5 步:停止一个现有的 etcd 服务器 {#step-5-stop-one-existing-etcd-server} 在停止服务器之前,请检查其是否为领导者。我们建议最后再停用领导者。如果要停止的服务器是领导者,可以在停止该服务器前通过 `move-leader` 将领导者角色转移至其他服务器,以减少停机时间。 ```bash etcdctl --endpoints=localhost:2379,localhost:22379,localhost:32379 move-leader 729934363faa4a24 < [!NOTE] > 与 v3.5 不同,v3.6 的状态端点会报告降级信息,因此降级中的成员会持续显示 `DOWNGRADE ENABLED` 为 true 以及其存储版本,直至降级完成。 #### 第 7 步:重复第 5 步和第 6 步,直至所有成员完成 {#step-7-repeat-step-5-and-step-6-for-rest-of-the-members} 当所有成员均完成降级后,降级操作将自动完成,`DOWNGRADE ENABLED` 被重置为 false。检查集群的健康状况和状态,确认所有成员的次要版本以及存储版本均为 v3.6: ```bash etcdctl --endpoints=localhost:2379,localhost:22379,localhost:32379 endpoint status -w=table <