更新与数据库迁移

2.2.1 可以从本分支现有正式版继续升级。较旧版本仍可能触发 2.1.12 引入的监控数据格式迁移；升级前后都应以页面显示的迁移状态为准，不要只看容器是否已经启动。

2.2.1 升级说明

• 系统 Web UI 与公共大屏主题已经解耦，主题不再控制后台、终端、初始化和错误页面。
• 默认提供 Nezha 主题。原经典主题不再随 Komari 捆绑，需要时可单独安装 komari-Classic。
• 主题管理必须至少保留一个可用主题，不能把公开大屏主题全部删除。
• 已有节点的流量统计方式保持原值；“总和”只作为新节点首次编辑时的默认选择。
• 已保存的历史图表 300s 刷新配置会按 120s 处理，实时概览和历史图表的新默认值均为 30s。
• 启动清理不会再删除 memory.total、swap.total、temperature 和 disk.total 等仍在使用的系统指标定义及历史数据。

升级前

1. 停止会修改数据的旧实例。
2. 备份程序和完整 data 目录。
3. 记录当前版本和七位构建码。
4. 确认磁盘有足够空间容纳旧库、迁移临时数据和 WAL。

Docker 更新

docker pull ghcr.io/nuomiiiii/komari:latest
docker rm -f komari

使用完全相同的 data 挂载重新创建容器。首次打开后台时，如出现迁移页面，请等待明确显示完成。

支持的来源

当前迁移路径覆盖：

• 已验证的上游 1.3.1、1.3.2 数据库来源。
• 本分支 2.1.7 至 2.1.11。
• 已经使用早期快照数据库格式的测试实例。

这里的“覆盖”只表示这些来源的数据迁移已适配，不表示 Lite 与上游的数据库结构、镜像或后台行为完全相同，也不自动包含未列出的上游版本。

升级会保留原有数据保留天数，并固定启用分层降采样；旧版低资源模式会停用。

迁移过程中会发生什么

• 页面显示当前阶段、进度和错误。
• 指标、延迟和丢包记录转换为新的无损紧凑格式。
• 旧数据每批成功后才清理；单批失败会回滚并保留原数据。
• 已删除服务器或探测任务的历史残留会被清理。
• SQLite 释放出的空闲页会优先复用，不一定立刻反映为文件变小。

不要中断正在写入的迁移

不要同时启动两个 Komari Lite 实例指向同一个 data 目录，也不要在迁移进行中手动替换数据库文件。

升级后检查

• 服务器在线状态和探测任务是否齐全。
• 历史曲线是否覆盖原有保留周期。
• 日报、周报、月报和计费流量口径是否符合设置。
• 数据库页面是否仍有迁移错误或待处理项目。
• 远程终端和文件管理能否通过当前反向代理建立连接。
• 公开大屏是否存在并启用了至少一个主题，服务器详情和网络排行跳转是否符合当前主题路由。
• 刷新页面或从公开大屏返回后，仪表盘是否先恢复上一帧并在后台静默更新。

如果希望立即把 SQLite 空闲页归还给磁盘，可在业务低峰期执行“回收空间”。这不是日常必做操作。