2026-10-28 11:14:17 +08:00

7.4 KiB
Raw Permalink Blame History

2026-09-21 操作日志

排查并修复云端「系统无法打开」(磁盘满)

  • 现象:静态首页能打开,POST /api/login 卡死;09:07 gunicorn 报 WORKER TIMEOUT (pid:968880),中断栈停在 services/db.py: conn.commit()。
  • 根因:磁盘 100% 满(40G 用 38G、可用 0)。08:30 每日备份导出 698M SQL 后打包时写满磁盘(gzip: stdout: No space left on device),备份中断;set -e 使得末尾 rm 未执行,698M 临时 SQL 滞留,MySQL 因无空间无法提交写入 → 登录请求 60 秒超时。
  • 累积备份约 25G:/opt/dy-dashboard-backups 12G、/opt/dy-dashboard_backups 4.5G、/opt/dy-dashboard/backups 3.4G、/home/ubuntu/dy-dashboard-backups 3.9G、/opt/backups 0.65G、/home/ubuntu/backups 0.71G。
  • 处理(清理范围先经旭东确认,选「清理 9/10 之前的旧备份 + 失败残留」):删除各备份目录 2026-09-10 之前的备份,并删除 698M 临时 SQL 与截断损坏的 85M 备份包;保留 09-10 以后备份、两份 full-cloud 全量备份、范围外的旧项目目录。
  • 结果:磁盘 100%(0 可用)→ 59%(16G 可用,释放约 15G);服务 active、本机 200(0.004s)、公网首页 200(0.34s)、登录 200(0.68s);重跑 backup.sh 成功(177M 项目包 + 59M 图片包)。
  • 待决(未擅自改):手工/部署备份目录加保留策略并覆盖 new_products_images_*;backup.sh 增加失败兜底与磁盘水位预检。
  • 未操作生产 11.79。

磁盘占用治理建议 + 每日备份保留策略

  • 定位「水龙头」:自动化任务「云端每日完整备份」每天 08:00 写 3.5G 全量包到 /opt/dy-dashboard-backups,无保留策略;全量包 tar 无排除项(含 venv/uploads/vault/logs 与每日备份包)。按此节奏每日约 +3.7G。
  • 给出六项建议(瘦身+留2份+降每周、每日目录保留策略、backup.sh 兜底、备份外移、系统层优化、磁盘告警)。
  • 旭东选定仅「每日备份目录加保留策略」,已执行:原脚本备份到 ~/dy-backups/backup-sh-pre-retention-20260921_094541/;backup.sh 清理段改为项目包保留 14 天 + 图片包保留 7 天(图片包此前从不清理);立刻清理一次删除 09-10~09-13 四份图片包(约 230M),目录 2.8G→2.5G。
  • 磁盘 59%(23G 用 / 16G 可用)、服务 active、本机 HTTP 200 正常。
  • 未执行:全量备份瘦身/保留/降频、backup.sh 兜底、备份外移、journald/binlog 优化、磁盘告警。

钉盘库存与日出库更新到 8.186 与云端

  • 11.79 离线(ARP FAILED / ping 丢包 / No route to host / 同网段无 18888,云端也不可达),未做任何读写;按旭东调整后的目标改同步 8.186 与云端。
  • 钉盘完整扫描:出库 820 文件(最新 09-20 wdt)、库存 1,566 文件(09-21 齐 21 仓)。
  • 两端缺口一致:出库 17 组合(09-18 八来源、09-19 八来源、09-20 wdt)、库存 21 组合(09-21 全部仓)。
  • 备份 38 个空切片 → 下载 38 个源文件(md5 两端一致)→ 两端各新增出库 6,781 条、库存 21,403 条。
  • 刷新 11 个缓存模块;8.186 用户级 systemd 重启、云端 kill -HUP;HTTP 本机/局域网/公网全 200。
  • 最终复核:两端缺口 0/0;38 组合行数一致;库存 09-21 可用 45,577,437、生产在途 1,685,627、采购在途 12,970,943;脏数据 0。
  • 累计:8.186 出库 398,918 / 库存 1,626,603;云端出库 405,799 / 库存 2,477,105。

打包 dy-dashboard 项目到桌面(排除每日备份)

  • 按旭东要求打包 ~/.openclaw/workspace/dy-dashboard 全部内容到桌面,排除每日备份文件。
  • 项目总 18G,其中 backups/(81 个备份目录)占 18G;仅排除该项,其余内容全量保留。
  • 打包后 905M(表观),输出 /home/gxd/桌面/dy-dashboard-20260921-1828.tar.gz(446M)。
  • 校验:归档条目 8,448 条、backups 相关条目 0;app.py、routes/(37)、services/(28)、static/(120)、templates/(6)、venv/(13)、dy_data_v1.0.sql、backup.sh、pack_deploy_full.sh 齐全;gzip -t 通过;MD5 ce62e6f578f83cca9167b2fd0b5a1eb1。
  • 未做任何删除,原项目保持原样;未操作生产环境。

智能体从 OpenClaw 迁移到 Codex 方案(仅计划,无部署)

  • 按旭东要求编制迁移方案,只出计划、无任何部署动作。
  • 实测盘点:OpenClaw 2026.9.4;配置 195 个代理但仅 4 个绑定钉钉在跑(采购助手、数据处理助手、数据处理工作助手、工作助手);203 个自动化任务中仅 9 个有业务价值,其余约 190 个为 skill-collection-review-* 每周自动生成、建议直接删除;4 个钉钉机器人共用 dingtalk-connector 插件(0.8.25);会话库 155MB;技能 3 插件 + 7 自建 + 1 全局;MCP 1 个。
  • 核心结论:Codex CLI 是编码代理,无通道、调度、多代理、记忆、技能注入与控制面,整套平移不存在。
  • 方案 A(推荐):Codex 做大脑、OpenClaw 保留外壳,3–5 天、零停机;方案 B:完全替换,需自建钉钉桥接服务、8 个 systemd timer、会话映射存储与失败告警通道,2–4 周。
  • 分阶段:Phase 0 冻结备份 → 1 Codex 单机只读对齐 → 2 造替代外壳 → 3 影子运行 → 4 逐任务切换 → 5 退役,各阶段设门禁与回滚路径。
  • 两条铁律:单一所有者(切换即停另一侧,防重复写库与重复回复);钉钉同一 clientId 不可两消费端并行,影子测试须新建测试机器人账号。
  • 明确不做:不碰 11.79 生产与云端、不动 dy-dashboard 代码与 MySQL、不迁 161MB 历史会话库、不迁未启用代理与噪音任务。
  • 方案文档:reports/2026-09-21-openclaw-to-codex-migration-plan.md;未操作生产与云端环境。

生成 dy-dashboard 云端部署文档

  • 按旭东要求编制云端(gyl.dieya.net.cn / ubuntu@82.156.135.91)部署文档,先实测核对再落笔,未执行任何部署动作。
  • 环境实测:/opt/dy-dashboard 非 Git 仓库;磁盘 40G 中 23G 已用、16G 可用(60%);dy-dashboard.service active(MainPID 1271894);Python 3.12.3(需用 venv);Gunicorn 18888;库 dy_data;52 张表。
  • 差异核对(只读):代码需同步 15 项——run.py、update_data.py、backup.sh、routes/(ai/inventory/planning/products/purchase)、services/(ai_datasources/db/field_perms)、static/js/app.js 与 app.js.gz;数据库结构无需迁移,云端多出 1 列 finished_products.待提数量 保留不删;bom_packaging.updated_at 与 packaging_orders.计划下单时间 仅列顺序差异、定义相同。
  • 文档:云端部署指南.md(项目根目录,13.5KB),含授权边界、部署前检查、备份与恢复、代码同步(定向 rsync 推荐 / 打包文件谨慎)、数据库结构增量迁移、代码自检与缓存、服务重载、验证探针、回滚、本次待部署内容、记录同步、常见故障速查、SSH 多行脚本写法约束。
  • 写明的红线:不覆盖云端 config.py 与 static/uploads、不删云端独有列或表、不动备份目录、不在云端跑 git;磁盘满表现为「页面能开、登录没反应」先查 df -h /;改 app.js 必须重建 app.js.gz;手工 SQL 导入后必须 refresh_all_caches();改单元文件须 daemon-reload + restart。
  • 未部署、未改云端任何文件、未操作 11.79 生产环境。