9d6ebbe422
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>
54 lines
1.8 KiB
Bash
Executable File
54 lines
1.8 KiB
Bash
Executable File
#!/bin/sh
|
|
# RETIRED 2026-09-12: production moved off the NAS to the Oracle box
|
|
# (systemd unit garmin-health-lab.service there). Kept for reference only.
|
|
# Start Garmin Health Lab. Safe to run repeatedly: an already-running
|
|
# instance is stopped first. Intended for DSM Task Scheduler (boot-up).
|
|
APP="$(cd "$(dirname "$0")/.." && pwd)"
|
|
cd "$APP/backend" || exit 1
|
|
|
|
GUNICORN="$APP/backend/.venv/bin/gunicorn"
|
|
|
|
# Stop whatever is already running, then WAIT for the port to actually be
|
|
# free. Killing only the pid in app.pid left orphaned workers holding :8124;
|
|
# the new master then started, reported success, and served nothing — the
|
|
# site was down while every log line looked normal.
|
|
"$APP/deploy/stop.sh" >/dev/null 2>&1
|
|
|
|
# `ps | grep`, not pgrep: DSM has no pgrep, so this loop used to fail with 127
|
|
# every second and wait the full 20s whether or not anything was still running.
|
|
alive() { ps -eo args 2>/dev/null | grep -q "^$GUNICORN"; }
|
|
|
|
i=0
|
|
while [ $i -lt 20 ]; do
|
|
alive || break
|
|
sleep 1
|
|
i=$((i + 1))
|
|
done
|
|
pkill -9 -f "$GUNICORN" 2>/dev/null
|
|
sleep 1
|
|
|
|
mkdir -p "$APP/logs"
|
|
# --timeout 300: an AI generation against the reasoning model can run for
|
|
# minutes, and gunicorn kills a worker that looks stuck before then.
|
|
nohup "$GUNICORN" \
|
|
--workers 2 --threads 4 --timeout 300 \
|
|
--bind 0.0.0.0:8124 \
|
|
--access-logfile "$APP/logs/access.log" \
|
|
--error-logfile "$APP/logs/error.log" \
|
|
wsgi:app > "$APP/logs/stdout.log" 2>&1 &
|
|
|
|
echo $! > "$APP/app.pid"
|
|
|
|
# Confirm it is actually serving rather than just running.
|
|
i=0
|
|
while [ $i -lt 25 ]; do
|
|
if curl -sf -m 2 -o /dev/null http://127.0.0.1:8124/api/health/status; then
|
|
echo "started pid $(cat "$APP/app.pid") on :8124"
|
|
exit 0
|
|
fi
|
|
sleep 1
|
|
i=$((i + 1))
|
|
done
|
|
|
|
echo "FAILED to serve on :8124 — see $APP/logs/error.log" >&2
|
|
exit 1 |