CentOS 7下MySQL服务启动失败的解决思路

本文记录了MySQL服务启动失败的问题排查过程。从systemctl提示到查看MySQL告警日志,最终定位为权限问题并解决了/var/run/mysqld/目录的属主和属组配置。
今天,启动MySQL服务器失败,如下所示:

# /etc/init.d/mysqld start
Starting mysqld (via systemctl): Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.
[FAILED]
根据提示,分别使用systemctl status mysqld.service和journalctl -xe查看服务启动失败的原因

# systemctl status mysqld.service

复制代码
?.mysqld.service - SYSV: MySQL database server.
Loaded: loaded (/etc/rc.d/init.d/mysqld)
Active: failed (Result: exit-code) since Wed 2016-01-20 18:26:57 CST; 40s ago
Docs: man:systemd-sysv-generator(8)
Process: 2979 ExecStart=/etc/rc.d/init.d/mysqld start (code=exited, status=1/FAILURE)

Jan 20 18:26:56 spark01 systemd[1]: Starting SYSV: MySQL database server....
Jan 20 18:26:57 spark01 mysqld[2979]: MySQL Daemon failed to start.
Jan 20 18:26:57 spark01 mysqld[2979]: Starting mysqld: [FAILED]
Jan 20 18:26:57 spark01 systemd[1]: mysqld.service: control process exited, code=exited status=1
Jan 20 18:26:57 spark01 systemd[1]: Failed to start SYSV: MySQL database server..
Jan 20 18:26:57 spark01 systemd[1]: Unit mysqld.service entered failed state.
Jan 20 18:26:57 spark01 systemd[1]: mysqld.service failed.
复制代码
# journalctl -xe

复制代码
--
-- Unit session-2.scope has begun starting up.
Jan 20 18:26:48 spark01 sshd[2916]: pam_unix(sshd:session): session opened for user spark by (uid=0)
Jan 20 18:26:52 spark01 su[2944]: (to root) spark on pts/1
Jan 20 18:26:52 spark01 su[2944]: pam_unix(su-l:session): session opened for user root by spark(uid=1000)
Jan 20 18:26:56 spark01 polkitd[909]: Registered Authentication Agent for unix-process:2974:117137 (system bus name :1.25
Jan 20 18:26:56 spark01 systemd[1]: Starting SYSV: MySQL database server....
-- Subject: Unit mysqld.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mysqld.service has begun starting up.
Jan 20 18:26:57 spark01 mysqld[2979]: MySQL Daemon failed to start.
Jan 20 18:26:57 spark01 mysqld[2979]: Starting mysqld: [FAILED]
Jan 20 18:26:57 spark01 systemd[1]: mysqld.service: control process exited, code=exited status=1
Jan 20 18:26:57 spark01 systemd[1]: Failed to start SYSV: MySQL database server..
-- Subject: Unit mysqld.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mysqld.service has failed.
--
-- The result is failed.
Jan 20 18:26:57 spark01 systemd[1]: Unit mysqld.service entered failed state.
Jan 20 18:26:57 spark01 systemd[1]: mysqld.service failed.
Jan 20 18:26:57 spark01 polkitd[909]: Unregistered Authentication Agent for unix-process:2974:117137 (system bus name :1.
复制代码
但,可惜的时,这些信息并不能提供服务启动失败的真正原因。

这时候,不妨打开MySQL的告警日志,毕竟,只要MySQL服务启动,告警日志都会有输出信息的,果然

2016-01-20T10:00:19.935771Z 0 [ERROR] /usr/sbin/mysqld: Can't create/write to file '/var/run/mysqld/mysqld.pid' (Errcode: 2 - No such file or directory)
2016-01-20T10:00:19.935795Z 0 [ERROR] Can't start server: can't create PID file: No such file or directory
160120 18:00:20 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
MySQL服务在启动的时候,不能创建pid文件。

在终端看一下该目录是否存在,果然,不存在。

于是,创建了/var/run/mysqld/目录,重启MySQL服务

# mkdir -p /var/run/mysqld/

# /etc/init.d/mysqld start

Starting mysqld (via systemctl): Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.
[FAILED]
依旧报错,重新查看告警日志,有以下输出

2016-01-20T10:28:37.183387Z 0 [ERROR] /usr/sbin/mysqld: Can't create/write to file '/var/run/mysqld/mysqld.pid' (Errcode: 13 - Permission denied)
2016-01-20T10:28:37.183431Z 0 [ERROR] Can't start server: can't create PID file: Permission denied
160120 18:28:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
160120 18:32:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
原来,/var/run/mysqld/的属主和属组还是root,mysql并不能在其中创建文件,后修改该目录的属主和属组,启动OK。

# ls -ld /var/run/mysqld/
drwxr-xr-x 2 root root 40 Jan 20 18:28 /var/run/mysqld/
# chown mysql.mysql /var/run/mysqld/
# /etc/init.d/mysqld start
Starting mysqld (via systemctl): [ OK ]


总结:

以前在玩Kubernetes的时候,常遇到启动失败的情况,根据systemctl的提示,通过systemctl status mysqld.service和journalctl -xe命令查看服务启动失败的原因往往并不如人意,反而给了一种错误的暗示,以为这个跟系统有关。其实,通过查看服务的日志,往往更能清晰的知道服务启动失败的原因。
<think>嗯,用户的问题是关于CentOS 7.9系统中重启MySQL服务数据库数量减少的解决方案。我需要先理解问题的具体情况。用户提到重启MySQL数据库数量减少,这可能涉及到数据目录的配置、权限问题,或者数据库文件本身的问题。 首先,我应该考虑数据存储路径是否正确。MySQL的数据通常存储在/var/lib/mysql目录下,但有时候配置可能有误,导致重启后指向了不同的目录。用户需要检查my.cnf配置文件中的datadir设置是否正确,确保指向了实际包含数据库文件的目录。如果配置错误,MySQL可能会使用默认路径,而那里没有原来的数据库,所以看起来数据库减少了。 接下来,文件权限和所有权也是常见问题。如果MySQL服务在重启后以不同的用户身份运行,或者文件权限被修改,可能导致无法读取数据目录中的文件,从而无法正确加载数据库。用户需要检查目录权限是否为mysql用户和组,并确认文件和子目录的权限是否正确,比如755或750。 另外,数据库文件损坏也是一个可能的原因。比如,如果InnoDB表空间文件损坏,MySQL可能无法启动或加载这些数据库。这时候需要查看错误日志,通常位于/var/log/mysql/或/var/log/mysqld.log,根据日志中的具体错误信息来诊断问题。如果发现损坏,可能需要使用innodb_force_recovery参数启动MySQL,然后进行数据导出和恢复。 还有,临时文件系统的问题。如果MySQL的数据目录被挂载为临时文件系统,重启后数据会丢失。用户需要检查/etc/fstab中的挂载配置,确保数据目录所在的文件系统是持久化的。 此外,SELinux可能会干扰MySQL的访问。在CentOS 7中,SELinux默认是启用的,如果配置不当,可能导致MySQL无法读取数据文件。用户可以考虑暂时禁用SELinux,或者调整策略,设置正确的上下文标签。 备份和恢复也是重要的步骤。如果之前的备份存在,可以通过mysqldump或物理备份恢复数据。用户提到之前尝试过mysqldump但导致MySQL崩溃,可能需要先修复数据库文件,再尝试导出。 还有,查看MySQL启动状态和日志是关键。使用systemctl status mysqld查看服务状态,确认是否有启动错误。同时,仔细阅读错误日志,寻找权限错误、文件丢失或损坏的信息。 最后,可能需要重新安装MySQL并恢复数据,或者联系数据库恢复专家,如果数据非常重要且无法自行修复的话。 综合这些思路,我需要逐步引导用户检查配置、权限、日志,并提供相应的解决步骤,同时提醒备份的重要性,以防止数据丢失。</think>### 分步解决方案:CentOS 7.9重启MySQL数据库数量减少的排查与修复 #### 1. 验证数据存储路径 - **检查my.cnf配置**: ```bash grep -i "datadir" /etc/my.cnf ``` 确认`datadir=/var/lib/mysql`是否指向实际数据库文件路径。若路径错误,修改后重启服务: ```bash systemctl restart mysqld ``` [^3] #### 2. 检查文件权限与所有权 - **设置正确权限**: ```bash chown -R mysql:mysql /var/lib/mysql chmod -R 750 /var/lib/mysql ``` 错误的权限会导致MySQL无法读取数据库文件[^2] #### 3. 分析错误日志 - **定位日志文件**: ```bash tail -n 100 /var/log/mysqld.log ``` 重点查找以下错误类型: - `[ERROR] Can't open file` - `[Warning] InnoDB: Tablespace not found` - `[ERROR] Found corrupted table` #### 4. 数据库恢复操作 - **强制恢复模式**(慎用): 在`/etc/my.cnf`添加: ```ini [mysqld] innodb_force_recovery=6 ``` 重启服务后立即导出数据: ```bash mysqldump -u root -p --all-databases > backup.sql ``` [^1] #### 5. 验证存储挂载类型 - **检查文件系统挂载**: ```bash df -Th /var/lib/mysql grep "/var/lib/mysql" /etc/fstab ``` 确认未使用tmpfs等易失性存储 #### 6. SELinux策略调整 - **临时禁用SELinux**: ```bash setenforce 0 systemctl restart mysqld ``` 若问题解决,需永久配置策略: ```bash semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?" restorecon -Rv /var/lib/mysql ``` #### 7. 数据库文件完整性检测 - **执行表检查**: ```sql mysqlcheck -u root -p --all-databases --check ``` 发现损坏表后使用: ```sql REPAIR TABLE damaged_table; ``` ### 典型问题场景验证表 | 现象 | 可能原因 | 验证命令 | 解决方案 | |------|----------|----------|----------| | 数据库"消失"但文件存在 | 权限问题 | `ls -l /var/lib/mysql` | 修正所有权 | | 服务启动失败 | 表空间损坏 | 查看错误日志 | 启用innodb_force_recovery | | 仅部分数据库可见 | 配置指向错误目录 | `mysqladmin variables | grep datadir` | 修改my.cnf配置 | ### 预防措施 1. 定期执行数据库备份: ```bash mysqldump -u root -p --all-databases | gzip > /backup/mysql_$(date +%F).sql.gz ``` 2. 配置监控告警: ```bash yum install nagios-plugins-mysql ``` 3. 使用事务性存储引擎: ```sql ALTER TABLE important_table ENGINE=InnoDB; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值