升级
各安装方式的升级命令、启动时自动执行的数据库迁移，以及回滚时的注意事项。
升级前
- 读一遍目标版本的 Release 说明。
- 留一份回滚用的元数据库副本：在后台「设置 → 备份与导出 → 元数据库快照」点「立即备份」，再「下载」这份快照，保存在服务器以外。也可以停服后复制
<数据目录>/imgyoung.db（停服后才是一致的）。 - 确认 master.key 已有备份，见配置。
当前版本可用 imgyoung -version 查看，或看后台「设置 → 运行配置 → 引导配置」里的「服务端版本」。
升级命令
重新执行安装脚本即升级到最新正式版；指定版本加 --version X.Y.Z。
# 用 systemd 服务运行的(当初加了 --service):替换二进制、重写服务单元并重启服务
curl -fsSL https://raw.githubusercontent.com/x-haose/imgyoung/main/install.sh | sudo sh -s -- --service
# 自己管理进程的:只替换二进制,之后自行重启 imgyoung
curl -fsSL https://raw.githubusercontent.com/x-haose/imgyoung/main/install.sh | sh--service 会用发布包里的 deploy/imgyoung.service 覆盖 /etc/systemd/system/imgyoung.service；自定义的环境变量请放在 systemctl edit 创建的 drop-in 里，不会被覆盖。
停止旧进程时，ImgYoung 先停止接收新请求，在途请求最多等 6 秒（超时强制断开），再停后台循环与在途的补齐任务，最多等 2 秒，然后关库退出。被打断的补齐任务下次启动由对账重新入队。Docker 默认的 10 秒停止时限，以及 deploy/ 示例里的 stop_grace_period: 15s（Compose）与 TimeoutStopSec=15s（systemd）都够用。
数据库迁移
数据库迁移打包在二进制里，每次启动、打开数据库之后自动执行：
- 先校验迁移文件与校验和清单一致，再按版本顺序应用所有尚未应用的迁移；跨多个版本升级时，中间版本的迁移会依次补齐。已应用的版本记录在数据库的
schema_revisions表里。 - 补齐子系统的任务队列表也在启动时迁移到当前版本。
- 新增的运营配置项由迁移按出厂默认值补齐，已有配置保持不变。
- 库里记有本二进制不认识的迁移版本（被更新的版本迁移过）时拒绝启动，见下文回滚。
- 迁移失败时进程以错误退出，日志给出失败的迁移文件名。此时用升级前的快照回滚（见下文）。
不需要也没有单独的迁移命令。
回滚
不支持降级：迁移只有升级方向，部分迁移会删除列或重建表。旧版本的二进制遇到被新版本迁移过的库会拒绝启动，错误信息写明库里的最新迁移版本与本二进制认识到的最新版本。
所以回滚只有一种做法：旧版本的二进制 + 升级前的快照。没有升级前的快照，就只能继续用新版本。
停止服务。
换回旧版本的二进制或镜像标签。
把升级前的快照（或停服时复制的数据库）放为 <数据目录>/imgyoung.db.restore，不要直接覆盖 imgyoung.db：启动时它被换入，新版本迁移过的库改名为 imgyoung.db.pre-restore-<UTC 时刻> 留存，并且渠道的绑定时刻随之重置。Docker 部署的文件属主须为 65532:65532，写入方法参考备份与恢复里借临时容器的做法。
启动服务。
升级之后产生的元数据随之丢失，影响与从快照恢复相同：这期间上传的图片在元数据里没有记录，它们在渠道上的对象只计数、不回收，但无法再通过 ImgYoung 访问，详见备份与恢复。