MySQL 与 Redis 恢复排障

本页只处理控制面的支撑层问题：MySQL、Redis、support 依赖，以及它们导致的连锁故障。

如果你已经确认问题在 CubeMaster、cube-api、模板或节点对象层，请转到对应专题页。

先冻结现场

恢复前建议先做：

保存 journalctl、/data/log/ 和最近变更信息
记录当前版本与部署形态
确认备份是否存在
暂缓 restoredb、清空数据目录、整组重装

支撑层恢复顺序

建议按下面顺序处理：

先做只读初判
先恢复 MySQL
再恢复 Redis
只有支撑层稳定后，才继续恢复 CubeMaster / cube-api

只读安全检查

建议先执行：

bash

sudo ./smoke.sh
curl -fsS http://127.0.0.1:19090/healthz
curl -fsS http://127.0.0.1:19090/readyz

同时检查：

.one-click.env
support 相关配置和 compose 文件
服务状态与端口监听
是否存在循环重启

MySQL 常见症状

端口不监听或启动失败

优先看：

服务状态
启动日志
容器/进程是否循环重启

上层报数据库连接失败

这通常说明支撑层还没稳定，不建议此时继续恢复 CubeMaster 或 cube-api。

Redis 常见症状

启动循环或连接超时

优先看：

服务状态
启动日志
上层是否大量出现访问异常

Dashboard / API 间歇异常

如果问题呈现为间歇性，而不是完全不可达，也要先怀疑支撑层抖动。

连锁症状怎么回溯

出现下面这些表现时，要先回到支撑层判断：

notify/health 失败
3000/health 失败
Dashboard 能开但管理操作持续异常
恢复后对象状态明显漂移

什么时候进入下一页

支撑层已稳定，但控制面仍然异常时，继续看：

MySQL 与 Redis 恢复排障 ​

先冻结现场 ​

支撑层恢复顺序 ​

只读安全检查 ​

MySQL 常见症状 ​

端口不监听或启动失败 ​

上层报数据库连接失败 ​

Redis 常见症状 ​

启动循环或连接超时 ​

Dashboard / API 间歇异常 ​

连锁症状怎么回溯 ​

什么时候进入下一页 ​

相关文档 ​