数据库突然不能挂载了，咋整才好，有啥办法能让它重新正常启动？

综合参考自多个数据库社区如Stack Overflow、CSDN以及阿里云、腾讯云等云服务商的常见问题排查文档）

数据库突然不能挂载,这确实是件让人头疼的事，感觉就像家里的钥匙突然打不开门了，别慌，咱们一步一步来，就像侦探破案一样，从最简单、最可能的地方开始检查，记住一个核心原则：在没搞清楚原因之前，千万不要轻易尝试那些看起来能“强力修复”的操作，比如直接重建数据库文件，那可能会导致数据彻底丢失。

第一步：保持冷静，先看“病历本”——日志文件

数据库自己有个“病历本”，就是日志文件，它不能挂载的时候，通常会在日志里写下“病因”，这是最直接、最准确的线索来源。

• 去哪找日志？ 这个取决于你用的数据库类型。
  • 如果是MySQL或MariaDB,日志文件通常叫 hostname.err，位置一般在数据目录下（/var/lib/mysql/），你也可以通过命令 show variables like 'log_error'; 来查看路径（现在数据库挂了，这个命令用不了，你得去配置文件里找或者凭记忆找默认位置）。
  • 如果是PostgreSQL,主要看 log 目录下的文件，postgresql-XX-main.log。
• 看什么？ 用文本编辑器或者 tail、cat 这些命令打开日志文件，重点看最后几十行或者几百行，特别是数据库最后一次尝试启动时记录的信息，里面经常会直接告诉你错误原因，
  • “磁盘空间不足”
  • “某个数据文件损坏或不见了”
  • “权限不对，数据库用户没权利读取文件”
  • “内存不够了”
  • 端口被别的程序占用了

很多时候,仅仅通过查看日志，你就能立刻知道问题所在，如果日志里明确写着 “No space left on device”，那你的首要任务就是去清理服务器磁盘空间了。

第二步：如果日志看不明白，或者没找到明显错误，开始“体检”

如果日志信息比较模糊,或者你不太会看，那我们就对数据库的运行环境做一个全面的“体检”。

1. 检查磁盘空间： 这是最常见的原因之一，不仅是数据库数据文件所在的分区，还包括系统的临时文件分区，有时候这些地方满了也会导致异常，用 df -h 命令查看各个分区的使用情况，如果某个分区使用率是100%，赶紧清理一下不必要的文件，比如旧的日志文件、临时文件等。

2. 检查文件权限： 数据库进程（比如mysql用户、postgres用户）必须对数据目录和里面的文件有读写的权限，有可能是不小心用root用户操作了数据文件，导致属主和权限变了，用 ls -l 命令查看数据目录的权限是否正确，比如MySQL的数据目录，通常属主应该是 mysql:mysql。

3. 检查内存和进程： 用 free -m 看看系统内存是否充足，如果内存耗尽，数据库进程可能会被系统强制杀掉，也可以用 ps aux | grep mysql（以MySQL为例）看看数据库进程是否存在，如果存在多个或者状态异常，可以尝试杀掉所有相关进程后再重启。

4. 检查端口占用： 数据库需要在特定的端口上监听（比如MySQL是3306），有可能这个端口被其他程序意外占用了，用 netstat -tulnp | grep 3306 这样的命令检查一下，如果被占用，要么停掉那个无关的程序，要么修改数据库的端口配置。

第三步：针对特定问题的“对症下药”

根据前面检查的结果,我们来进行修复。

• 磁盘空间不足。

  • 办法： 这是最简单的情况，赶紧腾出空间来，可以删除大型日志文件、备份文件，或者清理不必要的软件包，空间腾出来之后，再尝试重启数据库服务。

• 文件权限错误。

  • 办法： 使用 chown 和 chmod 命令，将数据目录的属主和权限改回正确的设置，对于MySQL：chown -R mysql:mysql /var/lib/mysql，改完之后再重启服务。

• 数据文件疑似损坏。 这是比较麻烦的情况。

  • 办法（以MySQL的InnoDB引擎为例）： 千万不要慌。确保你有最近的备份！ 这是你的救命稻草，可以尝试以下步骤：
    • 在数据库配置文件（如 my.cnf）中，在 [mysqld] 段落下添加一行 innodb_force_recovery = 1，这个参数会让InnoDB引擎以一种强制恢复模式启动，忽略一些错误。
    • 尝试启动数据库,如果启动失败，将数字增加到2，再试，这个参数从1到6，数字越大，忽略的错误越多，但数据一致性风险也越大。通常尝试到3或4如果还不行，就不要继续了。
    • 如果能在某个级别（比如3）成功启动，立刻、马上用 mysqldump 工具将数据库里的数据完整地导出（备份）出来，因为在这种恢复模式下，数据可能是只读的，而且不完全稳定。
    • 导出成功后,关闭数据库，移除 innodb_force_recovery 这行配置，然后用导出的SQL文件在一个新的、干净的数据库实例中重新导入数据。
  • 重要警告： 这个过程有风险，如果数据非常重要，而你又没有把握，最好先对当前的数据文件做一次完整的磁盘快照备份（如果是在云服务器上，这个功能很方便），然后再操作，或者直接求助更专业的人员。

• 彻底无法恢复，但有备份。

  • 办法： 如果以上方法都无效，而你又有最近的可用的备份，那么最后的办法就是“重建”，停止数据库服务，将当前损坏的数据目录重命名（相当于归档隔离，以防万一），然后创建一个新的空数据目录，恢复正确的权限，重新初始化数据库，最后将备份的数据导入进去。

第四步：养成好习惯，防患于未然

这次问题解决后,一定要思考如何避免下次再发生。

1. 定期备份！定期备份！定期备份！ 这是最重要的，而且要定期检查备份文件是否真的可以成功恢复。
2. 监控系统资源： 设置磁盘空间、内存、CPU使用率的报警，快满的时候就能提前收到通知，避免“突然”挂掉。
3. 操作规范： 对数据库进行任何重要操作（比如版本升级、数据迁移）前，先做备份，修改配置文件前先备份原文件。
4. 保持更新： 及时更新数据库版本，修复已知的bug，但生产环境更新前需要在测试环境充分验证。

数据库挂载失败就像生病,先观察症状（看日志），再做体检（查资源权限），然后对症下药，只要不急不躁，按照步骤来，大部分常见问题都是可以解决的，但如果数据极其重要且没有备份，而你又没有十足把握，最稳妥的办法是立即停止任何可能造成数据覆盖的操作，并寻求专业数据库管理员的帮助。