数据库起不来先取证再动手
数据库启动失败时反复执行拉起命令，只会不断产生新的日志与残留进程，让现场更乱。正确的做法是先取三处证据：服务管理器的状态摘要、数据库自身的错误日志、数据目录与磁盘状态。绝大多数启动失败都能从这三处直接读到原因。
高频根因集中在四类
磁盘空间不足导致无法写入或扩展文件；数据目录属主被动过导致数据库拒绝访问；配置被修改后参数不合法或路径失效；端口被残留进程占用。这四类都与「最近有什么变更」强相关，对比备份配置与变更记录能快速缩小范围。
基本信息
| 取证入口 | 服务状态、数据库错误日志、系统日志 |
|---|---|
| 日志位置 | 随产品不同，多在数据目录或安装目录下 |
| 关键检查 | 磁盘空间、目录属主、端口占用、最近配置变更 |
| 恢复前提 | 确认数据文件完整后再尝试启动 |
典型使用场景
- 服务器重启后数据库没有自动拉起，业务无法访问
- 磁盘写满后数据库异常退出，扩容后仍起不来
- 运维调整配置参数后数据库启动失败
- 同机部署多个实例，端口冲突导致其中一个起不来
- 数据目录被迁移或权限变更后实例无法启动
三处取证
三处取证
systemctl status <数据库服务名> --no-pager | head -20
journalctl -u <数据库服务名> --since '10 min ago' | tail -40
# 数据库自有错误日志（位置随产品而定，示例）：
# MySQL 类：数据目录下的错误日志或 /var/log 下同名日志
# 达梦：安装目录 log 目录 金仓：数据目录下的日志目录
ls -lt <日志目录> | head -5 # 找最近写入的日志文件根因快查
根因快查
df -h <数据目录> # 磁盘空间是否耗尽
ls -ld <数据目录> # 属主与权限是否正确
ss -lntp | grep <端口> # 端口占用，含残留进程
ls -l <配置文件> # 配置最近是否被改动
tail -50 <错误日志> # 直接读最后的报错行根因与处置
| 报错线索 | 根因 | 处置 |
|---|---|---|
| 写入失败或空间不足 | 磁盘写满 | 清理或扩容后重启，检查数据完整性 |
| 权限被拒绝 | 数据目录属主或权限被改 | 恢复属主与权限后重启 |
| 参数不合法 | 配置文件被修改 | 与备份配置对比后回退 |
| 端口已被占用 | 残留进程或实例重复启动 | 确认归属后再处理占用进程 |
| 数据文件损坏 | 异常断电或介质故障 | 按产品流程做恢复，勿反复尝试启动 |
启动失败不要反复强行拉起：每轮启动都会写日志并可能改动数据文件状态，先读明白日志再采取动作，需要恢复时优先使用备份与归档日志。