DAY013 – 订单数据库文件被移走

故障场景

故障现象：首页与 API health 正常，但订单接口返回 500，应用日志提示数据库文件无法打开。

服务器状态：

server2：状态 INJECTED；开始时间 2026-07-25 05:00:28 +0800；影响范围 演练项目受影响，SSH 不受影响，非演练业务不应受影响。

排障过程

先看项目文档

实际 curl 本地订单接口

查看后端日志

报错“error=no such table: orders”，没有找到对应的表，说明是数据库方面导致的问题

先看项目中代码是如何使用数据库的

可以看出数据库使用的 sqlite3，这个轻量数据库没有数据库服务器，环境变量中所指的 orders.db 就是数据库本身，所以我们主要花功夫在这个数据库文件上

看完代码后我们知道数据库文件在 /opt/hermes-drills/day013/data/orders.db

文件存在但是大小为 0，有可能本来没有文件，由于启动程序才被 sqlite3.connect("orders.db") 导致创建文件

发现没有任何表

是不是初始化数据库的过程出了问题

查找初始化数据库相关文件和代码

data 目录下有另外一份数据库相关文件，名称高度类似，并且检测 sql 代码中关于建表语句的命令也检测出 orders.db.moved 中有匹配内容

这次我放机灵点，ls 时把 -a 也加上，不错过隐藏文件

可以看到 orders.db.moved 占用 12KB，可能它才是真正我们需要的数据库

文件类型确实是数据库类型

看看它是不是存放有我们的 orders 表

当前可以判断 orders.db.moved 才是我们真正需要的数据库文件

现在应该保留现场，方便后期回溯，运维做事不做绝嘛。这只是个模拟故障的场景，实际生产环境，说不定就成删库事故了

恢复了

生产环境我们其实还应该看什么导致了这次事故并记录下来，确定责任

可以看审计日志、history 历史、grep -R 搜索相关脚本的关键字

但我这个环境时 codex 的脚本远程制造的，就先到这里了

原文首发于个人博客：liujixiang.de5.net