Linux服务器数据库启动不了，九成是日志、权限、端口或配置的问题，按顺序排查就能找到根因。
遇到数据库起不来,先别急着反复重启，更不要随手删文件，很多故障是被“越修越坏”的，我从一线运维踩过的坑里，把最常见的排查路径和修复方法给你捋一遍，每一步都是能直接上手的操作。
第一步：查日志，数据库不会无缘无故罢工
数据库起不来,第一件事不是猜原因，而是看它自己说了什么，日志文件会明确告诉你卡在哪一步，不同数据库日志路径不一样，但原理相同。
日志去哪找
- MySQL/MariaDB：常见路径是
/var/log/mysql/error.log或/var/log/mysqld.log，如果日志目录为空，可以看配置文件里log_error参数指定的位置。 - PostgreSQL：日志通常在
/var/log/postgresql/postgresql-版本-main.log，或者pg_log目录下。 - Oracle：通过
alert_log查看，一般在$ORACLE_BASE/diag/rdbms/<实例名>/<实例名>/trace/alert_<实例名>.log。
使用 tail -n 100 或 less 查看日志最后几十行，重点关注 ERROR、FATAL、failed 等字样，很多时候，原因就在最后几行里。
常见错误代码怎么读
| 错误信息片段 | 含义 |
|---|---|
No space left on device |
磁盘满了，写不了数据文件 |
Permission denied |
数据库进程没有权限访问数据目录或日志文件 |
Address already in use |
端口被别的进程占用 |
Can't connect to local MySQL server |
可能是socket文件缺失或进程没起来 |
inconsistent state |
数据文件损坏，需要恢复 |
数据库启动失败排查方法：从磁盘到权限逐个击破
业内专家指出,多数数据库启动失败集中在四个方面：磁盘、权限、配置、端口，按这个顺序排查，效率最高。
磁盘满了是最常见的原因
数据库写入需要磁盘空间,日志文件也一样，分区满了，进程初始化就会失败。
执行 df -h 查看挂载点使用率，重点关注数据目录所在分区，如果使用率达到100%，立刻清理日志或临时文件，别删数据库数据文件，先找 /tmp、/var/log、core dump
这类可清理项。
有时 df -h 显示还有空间，但 df -i 显示inode满了，很多小文件占满inode，也会导致创建新文件失败，两条命令都要跑。
权限不对：数据目录“进不去”
数据库进程通常以专用用户运行（MySQL是mysql用户，PostgreSQL是postgresql用户），如果数据目录属主不对，进程启动时读不到文件。
检查方法：
ls -ld /var/lib/mysql
输出显示属主应为mysql，如果不是，执行：
chown -R mysql:mysql /var/lib/mysql
PostgreSQL同理,数据目录属主应为postgresql，Oracle需要检查ORACLE_HOME和ORACLE_SID环境变量是否设置正确。
配置文件写错：一行参数导致全盘崩溃
如果最近改过my.cnf、postgresql.conf或spfile，启动失败大概率是配置问题。
用数据库自带校验工具提前检查：
- MySQL：
mysqld --validate-config - PostgreSQL：
postgres -D <数据目录> -c config_file=<配置文件>
常见错误包括：max_connections设置过大、innodb_buffer_pool_size超出内存、socket路径不存在、datadir路径写错。
如果记不清改了什么,直接对比备份的配置文件，没有备份？下次改配置前，一定先 cp 一份。
端口被占用：数据库“抢不到门牌号”
数据库默认端口（MySQL 3306，PostgreSQL 5432，Oracle 1521）被其他进程占用，就起不来。
查看端口占用：
netstat -tlnp | grep 3306
如果确实被占用,要么停掉占用进程，要么修改数据库监听端口，生产环境改端口需要同步改应用连接字符串，不建议临时改。
mysql数据库启动失败的处理流程
MySQL是Linux服务器上最常见也最容易出问题的数据库,单独说一说。
先看进程和socket
执行 ps -ef | grep mysqld，看进程是否存在，如果进程在但客户端连不上，多半是socket文件路径不对。
检查配置文件中的 socket 参数，常见为 /var/run/mysqld/mysqld.sock，如果该目录不存在，手动创建并修改属主：
mkdir -p /var/run/mysqld chown mysql:mysql /var/run/mysqld
数据目录损坏时如何找回数据
如果日志中出现 innodb corruption 或 Table doesn't exist，优先尝试：
mysqld --innodb-force-recovery=1
从1到6逐级增加,每级能跳过不同损坏环节，但要注意，这个模式会禁用写入操作，只能用来导出数据，数据导出后，尽快重建实例。
启动脚本失效的替代方案
使用 systemctl start mysqld 失败，但手动执行 /usr/sbin/mysqld 却能启动，说明系统服务文件有问题，检查 /etc/systemd/system/mysql.service 中的路径和用户配置，或者用 mysqld_safe & 临时启动。
PostgreSQL启动失败：像查体温一样查日志
PostgreSQL对一致性要求高,启动失败多数是数据目录状态不干净。
数据目录版本不匹配
如果升级过数据库,旧数据目录和新程序版本不兼容，启动日志会提示 database files are incompatible with server，这时需要运行 pg_upgrade 或恢复备份，不能直接启动。
共享内存设置不足
日志提示 could not map anonymous shared memory，说明内核kernel.shmmax参数太小，临时调整：
sysctl -w kernel.shmmax=17179869184
永久生效写入 /etc/sysctl.conf。
postmaster.pid 残留
数据库崩溃后,数据目录下会残留 postmaster.pid 文件，阻止启动，确认没有数据库进程在跑，可以删除该文件后重试。
Oracle数据库启动疑难：常见但冷门的环境变量问题
Oracle启动流程复杂,很多Linux服务器上的Oracle起不来，问题出在环境变量。
监听和实例要分开排查
lsnrctl status 看监听是否正常，sqlplus / as sysdba 进入实例后 startup，如果监听起来了但实例起不来，看 alert_log。
内存分配不匹配
Oracle使用SGA内存段,如果Linux内存参数变化，可能导致 ORA-27102: out of memory，执行 sysctl -p 刷新内核参数，或者调整 sga_target 大小。
文件权限需特别细心
Oracle的数据文件、控制文件、重做日志必须属于 oracle 用户且权限为 rw-r-----，用 ls -l 检查，不对就 chown oracle:oinstall 修改。
重启服务器后数据库起不来？修复思路要按顺序
服务器重启后数据库不自动启动,最常见的原因是系统服务没启用，或者数据库本身没能完成干净关闭。
检查服务开机自启
systemctl is-enabled mysqld
如果输出是 disabled，执行：
systemctl enable mysqld
PostgreSQL对应
systemctl enable postgresql，Oracle一般通过 /etc/oratab 配置自启，检查最后一行是否为 Y。
修复意外断电导致的损坏
突然断电最容易造成数据文件不一致,MySQL用 innodb_force_recovery 导出数据，PostgreSQL用 pg_resetwal 重置预写日志。
注意：pg_resetwal 是最后一招，它会跳过恢复日志，可能丢失最近提交的事务，操作前备份整个数据目录。
临时清理缓冲文件
某些情况下,数据库的共享内存段没有释放，重新启动时报 semget 或 shmget 错误，用 ipcs -m 查看残留的共享内存，用 ipcrm -m <shmid> 清理，再重启。
如果以上方法都无效，最后的救命手段
走到这一步,说明常规修复已经用尽，别硬扛，选一条最稳妥的路。
用备份恢复
检查是否有逻辑备份（mysqldump、pg_dump）或物理备份（XtraBackup、PGBackRest），恢复流程：
- 停掉当前数据库服务；
- 将现有数据目录重命名（保留现场）；
- 解压备份文件到数据目录,设置属主；
- 启动数据库,验证数据完整性。
如果备份是几天前的,也要接受少量数据丢失，总比没有备份强。
找专业团队介入
数据库起不来且数据重要,别反复尝试高风险操作，联系数据库运维服务商，提供日志文件和数据目录状态即可，专业团队能在不额外破坏数据的前提下，通过离线工具提取数据。
数据库启动失败排查，核心是先定位再动手
总结一句话：linux服务器数据库启动不了怎么办？查日志找原因，按磁盘、权限、配置、端口顺序排查，最后用备份兜底。 绝大多数情况都不需要重装系统或删除数据文件，平时做好备份，关键时刻才能睡得着觉。
Q&A：linux服务器数据库启动不了常见问题
数据库启动失败后，反复重启会损坏数据吗？
会,如果是数据文件损坏或磁盘故障，多次强制重启可能加重损坏，每次启动都会尝试读写数据文件，建议先确认日志原因，再决定是否重启。
没有备份的情况下数据库起不来，数据还能找回吗？
有概率,如果数据目录完整，只是进程起不来，可以用只读恢复模式或工具（如mysqld --innodb-force-recovery）尝试导出数据，如果文件系统损坏，需要用到 fsck 或专业恢复工具，但这时的数据找回率并不是100%，尽快断开写入操作，找有经验的人处理。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/761340.html
