环境
- 集群：cn-dev，namespace
restore-freetier-01
- 升级版本：v3.0.11 → v3.0.14-b0544ba46-2026-06-04
- 时间：2026-06-05
升级策略配置
UPGRADE_STRATEGY={"proxy":["dn"], "dn":["cn"], "cn":["log"], "log":[]}依赖关系：
log 无依赖，最先升级cn 依赖 log，在 log 之后升级dn 依赖 cn，在 cn 之后升级proxy 依赖 dn，最后升级
预期升级顺序：LOG → CN → DN → Proxy
实际升级过程
LOG 阶段（~08:50 - 09:12 UTC）
LOG-0、LOG-1、LOG-2 三个 pod 依次滚动重启，但 pod 之间的间隔时间不足以等待 Raft quorum 恢复。
DN 写入依赖 LOG 的 WAL 确认，LOG pod 重启期间 Raft leader 丢失，剩余 pod 需要重新选举 leader。由于控制器在一个 LOG pod 重启后未等待新 leader 选出、quorum 恢复，就继续重启下一个 LOG pod，DN 持续无法完成 WAL 写入，触发超时 panic：
| 时间 (UTC) |
DN 重启 |
累计 |
原因 |
| 08:52 |
+2 |
2 |
LOG-0 重启，Raft leader 丢失，DN WAL 超时 |
| 08:57 |
+2 |
4 |
LOG-1 重启，Raft 仍未稳定 |
| 09:02 |
+1 |
5 |
Raft quorum 未完全恢复 |
| 09:07 |
+1 |
6 |
同上 |
| 09:12 |
+1 |
7 |
LOG 升级收尾，DN 最后一次 panic |
DN 每次 panic 的错误日志：
FATAL: context deadline exceeded (WAL commit timeout due to Raft no leader)
结论：LOG 三个 pod 在约 20 分钟内全部重启完毕，期间 DN 因 Raft 不可用 panic 了 7 次。
CN 阶段（~09:12 - 09:22 UTC）
CN 收到 SIGTERM 后执行有序关闭（关闭组件 → 清理锁表 → 离开 gossip → 进程退出），然后新版本 pod 启动。
CN v3.0.14 启动成功，进程正常运行（CPU 0.4 核，内存 ~6.7GB，能执行 SQL），但未向 HAKeeper 发送心跳，HAKeeper 持续报 no CN available，Proxy 无法发现 CN，所有经 Proxy 的连接失败。
此状态持续 45+ 分钟未自行恢复。（CN 心跳不注册属于 MO 内核问题，非 operator 问题，已在 matrixone#24866 跟踪。）
DN 阶段（~09:27 UTC）
DN 升级重启（v3.0.11 → v3.0.14），这是正常的升级行为，重启 1 次。
Proxy 阶段（~09:35 - 09:48 UTC）
- 09:35 proxy-pddkw 升级到 v3.0.14
- 09:48 proxy-tfn4w 升级到 v3.0.14
此时 CN 仍未注册到 HAKeeper，升级控制器在 CN 阶段未通过健康检查的情况下继续推进了 Proxy 升级。
最终状态
所有组件镜像均为 v3.0.14，集群可手动连接执行 SQL，但 CN 心跳未恢复到 HAKeeper。
| 组件 |
升级重启次数 |
异常重启次数 |
| LOG-0/1/2 |
各 1 次 |
0 |
| CN |
2 次 |
0（但心跳未注册） |
| DN |
1 次（升级） |
7 次（级联 panic） |
| Proxy-pddkw |
1 次 |
0 |
| Proxy-tfn4w |
1 次 |
0 |
建议
1. 在 rolling update 的每个 pod 间增加稳定等待窗口
当前控制器重启一个 pod 后，确认该 pod Running/Ready 就继续下一个。但 Ready 不等于组件功能完全恢复。
建议对 LOG 组件增加：
- 等待 Raft leader 选举完成（可通过 HAKeeper API 或 Raft 状态检查）
- 等待 Raft quorum 恢复（确认集群可以正常处理写入）
- 再开始下一个 pod 的重启
2. 增加阶段间的健康门禁
在每个组件阶段完成后，检查该组件是否真正健康，再推进下一阶段：
| 阶段 |
健康门禁条件 |
| LOG |
Raft leader 存在 + quorum 恢复 + 所有 LOG pod Ready |
| CN |
CN 已向 HAKeeper 注册 + 心跳正常 + 所有 CN pod Ready |
| DN |
DN 无 FATAL 日志 + heartbeat 正常 + DN pod Ready |
| Proxy |
至少一个 Proxy pod 可路由请求 |
3. 增加 DN 对 LOG 短暂不可用的容忍
DN 的 WAL commit timeout 在 LOG 升级期间过于敏感，可以考虑：
- 在升级窗口内适当放大 DN 的 heartbeat/WAL timeout
- 或在 operator 侧通过 annotation 通知 DN 进入升级容忍模式
环境
restore-freetier-01升级策略配置
UPGRADE_STRATEGY={"proxy":["dn"], "dn":["cn"], "cn":["log"], "log":[]}依赖关系：
log无依赖，最先升级cn依赖log，在 log 之后升级dn依赖cn，在 cn 之后升级proxy依赖dn，最后升级预期升级顺序：LOG → CN → DN → Proxy
实际升级过程
LOG 阶段（~08:50 - 09:12 UTC）
LOG-0、LOG-1、LOG-2 三个 pod 依次滚动重启，但 pod 之间的间隔时间不足以等待 Raft quorum 恢复。
DN 写入依赖 LOG 的 WAL 确认，LOG pod 重启期间 Raft leader 丢失，剩余 pod 需要重新选举 leader。由于控制器在一个 LOG pod 重启后未等待新 leader 选出、quorum 恢复，就继续重启下一个 LOG pod，DN 持续无法完成 WAL 写入，触发超时 panic：
DN 每次 panic 的错误日志：
结论：LOG 三个 pod 在约 20 分钟内全部重启完毕，期间 DN 因 Raft 不可用 panic 了 7 次。
CN 阶段（~09:12 - 09:22 UTC）
CN 收到 SIGTERM 后执行有序关闭（关闭组件 → 清理锁表 → 离开 gossip → 进程退出），然后新版本 pod 启动。
CN v3.0.14 启动成功，进程正常运行（CPU 0.4 核，内存 ~6.7GB，能执行 SQL），但未向 HAKeeper 发送心跳，HAKeeper 持续报
no CN available，Proxy 无法发现 CN，所有经 Proxy 的连接失败。此状态持续 45+ 分钟未自行恢复。（CN 心跳不注册属于 MO 内核问题，非 operator 问题，已在 matrixone#24866 跟踪。）
DN 阶段（~09:27 UTC）
DN 升级重启（v3.0.11 → v3.0.14），这是正常的升级行为，重启 1 次。
Proxy 阶段（~09:35 - 09:48 UTC）
此时 CN 仍未注册到 HAKeeper，升级控制器在 CN 阶段未通过健康检查的情况下继续推进了 Proxy 升级。
最终状态
所有组件镜像均为 v3.0.14，集群可手动连接执行 SQL，但 CN 心跳未恢复到 HAKeeper。
建议
1. 在 rolling update 的每个 pod 间增加稳定等待窗口
当前控制器重启一个 pod 后，确认该 pod Running/Ready 就继续下一个。但 Ready 不等于组件功能完全恢复。
建议对 LOG 组件增加：
2. 增加阶段间的健康门禁
在每个组件阶段完成后，检查该组件是否真正健康，再推进下一阶段：
3. 增加 DN 对 LOG 短暂不可用的容忍
DN 的 WAL commit timeout 在 LOG 升级期间过于敏感，可以考虑：