飞牛相册（trim.photos）启动失败修复记录

妄xx

飞牛相册（trim.photos）启动失败修复记录

最近遇到飞牛相册启动失败，日志一直卡在数据库升级阶段，现把排查和修复过程整理一下，供大家参考。

一、现象

飞牛相册 trim.photos 启动后一直起不来，日志里反复出现：

failed to execute SQL in file /var/apps/trim.photos/target/upgrade/1007.sql:
duplicate column name: time_zone_offset

同时，服务日志里也一直显示：

trim.photos is not running

---

二、根因判断

我把 photo.db 拷贝到本地检查后发现：

1. 数据库结构其实已经升级过了

在表结构里，photo 和 user_photo 表都已经有 time_zone_offset 字段了。

2. 但版本号只停在 1006

数据库里的升级版本记录是：

1001
1002
1003
1004
1005
1006

没有 1007。

这就导致程序每次启动都会再次执行 1007.sql，而这个脚本又要重复添加 time_zone_offset，于是报：

duplicate column name: time_zone_offset

3. 数据库本身还有轻度损坏

PRAGMA integrity_check 还发现了索引异常：

row 1064 missing from index idx_p_file_dir_content_identifier

说明 photo.db 不只是版本号不一致，数据库文件本身也有结构损坏/索引不完整。

---

三、最终修复思路

我这次采取的修复方式是：

1. 先备份

先把原始数据库目录完整备份。

2. 修正版本号

把 photo.db 里的 db_version 补到 1007，避免程序再次重复执行 1007.sql。

3. 处理 SQLite 的 WAL 文件

因为目标目录下除了 photo.db，还有：

• photo.db-wal
• photo.db-shm

所以不能只替换 photo.db，否则旧 WAL 可能把状态重新回放回来。

最终做法是：

• 替换 photo.db
• 删除/移走旧的 photo.db-wal 和 photo.db-shm

4. 其他库不动

这次只处理了：

• photo.db

queue.db 和 system.db 没有动。

---

四、推荐操作步骤

如果大家遇到类似问题，可以按下面方式处理：

1）先停服务

停止 trim.photos。

2）备份现有数据库

备份整个目录：

/usr/local/apps/@appdata/trim.photos/db/

至少保留：

• photo.db
• photo.db-wal
• photo.db-shm

3）替换修复后的 photo.db

将修复过的 photo.db 覆盖到目标目录。

4）清理 WAL/SHM

删除或移走旧的：

photo.db-wal
photo.db-shm

5）重启服务

重新启动 trim.photos。

---

五、验证方式

启动后看日志：

修复前会有

duplicate column name: time_zone_offset

修复后应该不再重复出现这个报错

如果仍然有异常，再检查：

sqlite3 photo.db "PRAGMA integrity_check;"
sqlite3 photo.db "SELECT * FROM db_version ORDER BY version_code;"

---

六、补充说明

我这次排查过程中发现：

• photo.db 的版本号没同步到 1007
• time_zone_offset 其实已经存在于表结构中
• WAL 文件存在时，直接替换单独的 photo.db 可能不够
• 数据库还有一个索引损坏问题，说明库状态并不完全健康

所以这个问题本质上是：

数据库迁移状态不一致 + SQLite WAL/索引损坏

---

七、总结

这次能解决，核心就两点：

1. 把 db_version 补到 1007
2. 替换 photo.db 时，同时处理 photo.db-wal 和 photo.db-shm

如果你的飞牛相册也卡在：

duplicate column name: time_zone_offset

可以优先按这个方向排查。