Cube Sandbox

简体中文

English

简体中文

English

Appearance

控制节点与数据库恢复实操 ​

本页是 控制面恢复与元数据排障 的实操版，面向控制节点、MySQL、Redis、CubeMaster 和 cube-api 的恢复操作。

它更像恢复 runbook，而不是通用排障页。

适用场景 ​

适合以下情况：

  • 控制节点宕机或恢复后控制面不健康
  • MySQL / Redis 异常导致上层服务不可用
  • CubeMaster 或 cube-api 无法稳定启动
  • 升级后健康检查恢复，但元数据状态明显漂移

先冻结现场 ​

恢复前建议先做：

  1. 记录当前版本和最近一次变更
  2. 保存关键日志和配置快照
  3. 确认备份是否存在且版本兼容
  4. 暂缓高危写入动作

相关文档：

只读初判清单 ​

建议先按下面顺序确认：

bash
sudo ./smoke.sh
curl -fsS http://127.0.0.1:19090/healthz
curl -fsS http://127.0.0.1:8089/notify/health
curl -fsS http://127.0.0.1:3000/health
curl -fsS http://127.0.0.1:12088/cubeapi/v1/health

如果支撑层没有恢复，不要急着恢复上层服务。

恢复顺序总览 ​

建议严格按依赖顺序：

  1. 先恢复 MySQL
  2. 再恢复 Redis
  3. 再恢复 CubeMaster
  4. 再恢复 cube-api
  5. 最后恢复 cube-proxy、WebUI、CoreDNS

每一步进入下一步前，都应确认上一层已经健康。

支撑层恢复 ​

MySQL ​

优先检查：

  • 服务状态
  • 容器或进程是否反复重启
  • 端口是否监听
  • 启动日志是否持续报错

Redis ​

优先检查：

  • 服务状态
  • 是否存在启动循环
  • 是否能被上层服务访问

如果 MySQL / Redis 明显不稳定，不要继续重启 CubeMaster 或 cube-api。

控制面恢复 ​

CubeMaster ​

只有在依赖稳定后，才建议恢复 CubeMaster。

优先检查：

  • 8089/notify/health
  • 启动日志与业务日志
  • 节点和元数据接口是否可读

cube-api ​

建议在 CubeMaster 健康后再恢复 cube-api。

优先检查：

  • 3000/health
  • API 是否能正常读取关键对象
  • Dashboard 同源管理接口是否恢复

恢复后复验 ​

控制面恢复后，建议继续验证：

  1. 节点是否重新出现在控制面
  2. 模板列表是否可读
  3. 关键模板状态是否正常
  4. 至少一个沙箱关键路径是否可用

如果基础服务已恢复，但模板、副本、节点状态仍不一致，请转到对应专题页继续处理。

不要先做什么 ​

恢复过程中，建议避免：

  • 一上来就整组重启或重装
  • 在 MySQL / Redis 未稳定时恢复上层服务
  • 跳过只读比对直接执行 restoredb
  • 控制面未稳时就把问题归到节点替换或模板重建

相关文档 ​