第三章　数据库与应用排错

先说一句大实话

数据库和应用排错的核心，是分清“容器的事”还是“数据的事”。 1Panel 里几乎所有应用都以 Docker 容器方式运行，数据库也一样。容器坏了可以重建、可以重启，大不了重装；数据坏了就是真的坏了。所以这一章的每一节，都会优先保护数据，再谈修复。

一个数据库请求要闯几道关

和第二章的网站排错一样，先把路径画出来。以“网站连不上 MySQL”为例：

网站代码
   ↓ 读取连接信息（地址、端口、账号、密码）
Docker 网络
   ↓ 容器之间能不能互通
MySQL 容器
   ↓ 端口监听、服务存活
数据库账号权限
   ↓ 这个用户能不能从客户端的 IP 连进来
具体数据库
   ↓ 有没有这个库、表

“连不上数据库”这五个字，在这条链上至少有五个不同的故障点。第三章的方法论就是：别问“为什么连不上”，问“连到哪一步断了”。

举个具体的例子：网站报“数据库连接失败”，可能的原因包括——MySQL 容器没起来、网站和 MySQL 不在同一个 Docker 网络、数据库账号的访问权限只允许本地、连接信息里的端口填错了、磁盘满了导致 MySQL 拒绝写入。症状完全一样，处理方式完全不同。 所以这一章请你先记住一件事：症状不能定位问题，日志才能。

三类问题，三种处理方式

一个不变的铁律：不管是哪类问题，在动任何“修复”动作之前，先想办法把当前状态备份下来。1Panel 的备份是文件级别的，数据库用 mysqldump，网站和应用也各有备份入口。备份花了三分钟，能救你三个小时。

两个最常用的排错入口

第一个：容器日志。 应用商店安装的应用、数据库，点进详情基本都能看日志；服务器上也可以直接 docker logs 容器名。容器起不来，日志第一行往往就写着原因——端口冲突、权限不足、配置文件错。

第二个：任务日志。 日志审计 → 任务日志，应用安装、升级、备份、恢复都是异步任务，失败原因全在这里。“装到一半失败”、“备份失败”这类问题，先来这里看报错原文。

一个真实的工作习惯：数据库和应用出问题时，第一件事不是点“重启”，而是 docker ps 看一眼容器状态。Exited 和 Restarting 是两种完全不同的问题，日志会告诉你差别。

一个重要的区别：本地数据库与远程数据库

1Panel 的数据库管理支持两种来源：

排错前先确认这个数据库是哪种。远程数据库挂了，你在这台服务器上重启 Docker 是没有用的——问题根本不在这儿。数据库列表上方的下拉菜单可以切换实例，别在错误的实例上查半天。

这一章解决四个问题

如果时间有限只能记一句话，就记这一句：这一章的所有问题，都先从“日志”开始查，不从“现象”开始猜。

一个警告：别在生产上现学

数据库和应用的操作有几个动作是不可逆的：删库、恢复备份（覆盖现有数据）、升级（数据结构可能变化）。在你不确定的时候，宁可多查十分钟文档，也别点那个“确认”。1Panel 的官方文档对每个功能都有说明，不确定的操作先查：1Panel 官方文档：数据库。

这一章反复出现的概念

一条有意思的规律

应用类问题和网站类问题（第二章）有个重要区别：网站的问题大多“看得见”——浏览器一开就知道；应用的问题大多“藏得深”——容器跑得好好的，接口可能已经报错。所以应用排错更依赖日志和任务状态，而不是界面。

养成两个小习惯会很有帮助：

• 装完任何应用，先打开一次再走，别等三天后才发现根本没装好；
• 重要应用定期看一眼容器状态，Exited 和 Restarting 的容器不会主动告诉你。

下一节：从最常见的“数据库连不上”开始——三个层次、三种症状，一套标准的排查流程。