ericwyuan
|
9d6ebbe422
|
ops: 生产从 NAS 整体迁移到甲骨文云主机
NAS 局域网 IP 因重启被 DHCP 换过两次，磁盘/网络稳定性都不如已经跑着好几个
生产服务的甲骨文机器。整体搬迁：应用 + 数据库都搬走，NAS 只保留 Gitea（这个
仓库的源码托管，未动）。
## 迁移过程（已核对无损）
- MariaDB：NAS 导出（10.11 源库，处理了只有新版本才有的 `/*M!999999` 注释）
→ 导入甲骨文 MariaDB 10.3.39，**20 张表逐条精确 COUNT(*) 比对完全一致**
- 冻结 NAS（停服务）后又 dump 一次核对，确认期间零数据差异，才继续删库
- NAS `garmin_health_lab` 已 DROP DATABASE，备份在本地
`~/Desktop/Work/backups/garmin_health_lab_nas_backup_20260912.sql.gz`
- 应用部署到 `/opt/garmin-health-lab`，systemd 单元（`ubuntu` 用户，非
root），和这台机器上的 ai-gateway/auth-hub 同一套约定
- 公网：`https://garmin.zichuan.xyz`，DNS + Caddy 反代 + 自动 TLS，替代原来
`NAS frpc → 甲骨文:8124` 那条隧道（已从 NAS 的 frpc.toml 精确删除对应段，
其它转发未动，改完逐条复检过没打断）
- auth-hub 回调地址换成新域名，NAS/旧端口那几条历史回调已清掉
- AI 网关配置改本地回环（网关现在同机了），触发真实生成验证过
## 一个当场拦下来的风险
甲骨文部署完默认开着自动同步。迁移窗口期两边并行跑时，若两边的调度器同时去
刷新 Garmin 令牌，会撞上按账号计算的 SSO 限流（`GarminHealthLab` 仓库
2026-09-03 那次事故的根因，那次修复花了一整天）。确认账号级 auto_sync 设置
本来是关的、这次算侥幸没撞上——不是设计上的保险，所以迁移期间显式在甲骨文这边
加了 `AUTO_SYNC=false`，直接在运行进程里验证过生效，确认 NAS 已冻结、数据无
缺口后才打开。
## 文档 / 脚本同步
CLAUDE.md 明确写过"部署位置会变，排障前先查、不要凭记忆"——这次是第二次踩中
同一类问题（上次是"NAS 有没有生产环境"判断错），所以把 CLAUDE.md / PROGRESS.md
/ README.md / docs/* 里的部署事实全部更新，NAS 时代的 `deploy/` 脚本加废弃
说明保留参考、不删除，新增 `deploy/push_oracle.sh`（当场跑通一次真实部署）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
2026-09-12 23:53:15 +08:00 |
|
ericwyuan
|
317cb4996d
|
fix(deploy): 构建前端后复制到 backend/static/，避免部署旧版
之前 deploy.sh 只打包了 backend/ 目录，但前端构建输出在
client/build/，从未被复制到 backend/static/，导致部署的
始终是旧版前端。现在在 build 后自动复制。
|
2026-09-01 19:00:42 +08:00 |
|
ericwyuan
|
526ece7d14
|
refactor(sync): 手动同步与自动同步彻底分开
「历史范围」原本放在设置页，却只对同步页的一个按钮起作用；而同步页最
显眼的主按钮「同步最新数据」写死 2 天，根本不看这个设置。选了「全部
历史」再点主按钮，表现就是应用无视你 —— 这正是反复出现的「只同步下来
两天」。
现在两条链路各管各的：
* 自动同步：只在设置页配置（开关 + 频率），窗口固定 SYNC_DAYS，不再
读 history_days。措辞也改成「拉取最近几天」，不再暗示会补历史。
* 手动同步：范围就在同步页当场选，紧挨着用它的按钮，并标出每个范围的
实际代价（自上次同步 / 7 天 / … / 全部历史约 730 天、20-40 分钟）。
两个按钮合成一个「开始同步」，写死 2 天的那个删掉。
history_days 保留为「上次手动选的范围」，只有同步页读它；默认值改成
-1（自上次同步），对日常使用是正确的起点。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 09:20:52 +08:00 |
|