mysql启动失败排查

修改mysql配置文件之后,使用service mysqld restart 重启,发现停止成功但是启动失败了。

Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

系统提示通过 systemctl status mysqld.service  或者 journalctl -xe 命令来查看详情。我们一个一个来分析。

 

1、执行 systemctl status mysqld.service

[root@lee ~]# systemctl status mysqld.service
● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: deactivating (final-sigterm) (Result: exit-code) since Wed 2019-05-15 08:54:07 CST; 50s ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 32685 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
  Process: 32668 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 30830 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/mysqld.service
           └─32689 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

May 15 08:54:57 lee systemd[1]: mysqld.service holdoff time over, scheduling restart.
May 15 08:54:57 lee systemd[1]: Starting MySQL Server...
May 15 08:54:57 lee systemd[1]: mysqld.service: control process exited, code=exited status=1

通过上面标红的错误信息我们可以看到,mysqld主进程没有启动起来,其他就没有什么详细信息了。我们接着往下看。

 

2、执行 journalctl -xe 

May 15 09:03:17 lee systemd[1]: Unit mysqld.service entered failed state.
May 15 09:03:17 lee systemd[1]: mysqld.service failed.
May 15 09:03:17 lee systemd[1]: mysqld.service holdoff time over, scheduling restart.
May 15 09:03:17 lee systemd[1]: Starting MySQL 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.
May 15 09:03:17 lee mysqld[10921]: Initialization of mysqld failed: 0
May 15 09:03:17 lee systemd[1]: mysqld.service: control process exited, code=exited status=1
May 15 09:03:19 lee systemd[1]: Failed to start MySQL 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.

没啥有用的信息,就告诉我们启动失败了。

 

3、现在我们就只知道主进程执行不成功,其他信息一无所知,这可咋整。

作为一个程序员出了问题自然是想到看日志来查找原因,我们来看看mysql的启动日志。首先看下my.cnf中日志的位置,log-error=/var/log/mysqld.log,我的日志是存在这了,打开日志看个究竟。

最后面能看到这么一大坨的东西,看下日志时间相差了8小时,这是因为我没有去配置时区,当然这个不是重点。

2019-05-15T01:08:24.682793Z 0 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX'
2019-05-15T01:08:24.682795Z 0 [Note] Shutting down plugin 'INNODB_CMPMEM_RESET'
2019-05-15T01:08:24.682797Z 0 [Note] Shutting down plugin 'INNODB_CMPMEM'
2019-05-15T01:08:24.682799Z 0 [Note] Shutting down plugin 'INNODB_CMP_RESET'
2019-05-15T01:08:24.682800Z 0 [Note] Shutting down plugin 'INNODB_CMP'
2019-05-15T01:08:24.682802Z 0 [Note] Shutting down plugin 'INNODB_LOCK_WAITS'
2019-05-15T01:08:24.682804Z 0 [Note] Shutting down plugin 'INNODB_LOCKS'
2019-05-15T01:08:24.682806Z 0 [Note] Shutting down plugin 'INNODB_TRX'
2019-05-15T01:08:24.682807Z 0 [Note] Shutting down plugin 'InnoDB'
2019-05-15T01:08:24.684767Z 0 [Note] InnoDB: FTS optimize thread exiting.
2019-05-15T01:08:24.684867Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2019-05-15T01:08:24.684972Z 0 [Note] InnoDB: Buffer pool(s) load completed at 190515  9:08:24
2019-05-15T01:08:24.685009Z 0 [Note] InnoDB: Starting shutdown...
2019-05-15T01:08:24.785342Z 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
2019-05-15T01:08:24.785563Z 0 [Note] InnoDB: Buffer pool(s) dump completed at 190515  9:08:24
里面也没啥关键信息,这么多看起来贼烦,我们来过滤下。

执行   tail -n500 /var/log/mysqld.log|grep -E 'Warning|ERROR'

2019-05-15T01:12:38.934502Z 0 [ERROR] unknown variable 'binlog_fromat=mixed'
2019-05-15T01:12:38.934522Z 0 [ERROR] Aborting
2019-05-15T01:12:40.984590Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-05-15T01:12:41.188849Z 0 [ERROR] unknown variable 'binlog_fromat=mixed'
2019-05-15T01:12:41.188873Z 0 [ERROR] Aborting
2019-05-15T01:12:43.228937Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-05-15T01:12:43.431933Z 0 [ERROR] unknown variable 'binlog_fromat=mixed'
2019-05-15T01:12:43.431951Z 0 [ERROR] Aborting
到这里就很明显能看出问题了,提示未知参数,我们的英文单词拼错了。你问我怎么会敲错的,因为是信了网上亲测可用的这些帖子的邪了。这要是可用我把小牛子都给你揪下来。

4、总结

对于mysql启动报错我们可以通过如下的步骤来排查。

①:systemctl status mysqld.service 命令,通过这个我们能很快定位到出错的进程。

②:journalctl -xe 命令,作为上一步的补充能够进一步佐证我们的判断。

③:查看mysql的日志,这个是最重要的。因为绝大部分成熟的产品一定会考虑用户的使用,mysql从载入内存开始,后续的操作都会记录到日志当中。所以我们在使用mysql时出现类似问题,大概率都能从日志文件中找到问题,加以分析就能解决了。

 

 

### MySQL 启动失败的原因分析 MySQL启动失败可能由多种因素引起,常见的原因包括但不限于: - **权限不足**:如果未以管理员身份执行命令行操作,则可能导致安装或启动服务时出现问题[^1]。 - **端口冲突**:默认情况下,MySQL 使用 3306 端口。如果有其他应用程序占用了该端口,MySQL 将无法正常启动。 - **配置文件错误**:`my.cnf` 或 `my.ini` 文件中的设置不当也可能阻止 MySQL 正常工作。例如,指定的数据目录不存在或者路径不正确。 - **依赖项缺失**:某些操作系统上的 MySQL 可能依赖于特定库或其他组件的存在;缺少这些必要的资源会妨碍其成功初始化。 - **日志记录问题**:查看 MySQL 的错误日志可以帮助诊断具体是什么地方出了错。通常可以在数据目录下的 `hostname.err` 文件中找到线索。 对于提到的具体情况——即通过 Homebrew 安装的 MySQL 报告 “ERROR 2002 (HY000)” 错误消息,这表明客户端尝试连接本地 MySQL 实例时遇到了障碍,可能是由于 Unix 域套接字 `/tmp/mysql.sock` 不可用所引起的[^3]。 为了进一步排查并解决问题,建议按照以下方法逐一验证和处理潜在的问题点: #### 验证 MySQL 是否已正确安装和服务状态 可以先确认 MySQL 是否已经作为一个有效的系统服务存在,并检查当前的服务状态。如果是 Linux 系统,可利用如下指令来获取相关信息: ```bash sudo systemctl list-units --type=service | grep mysql sudo systemctl status mysql.service ``` 对于 macOS 用户来说,当使用 Homebrew 来管理软件包时,应该采用 brew services 子命令来进行相应的查询: ```bash brew services list ``` #### 排查网络接口与监听地址 有时即使 MySQL 进程处于活动状态,但如果它被配置成仅绑定到 localhost 而不是所有网卡上的话,外部访问就会受到限制。此时应当调整 my.cnf 中 bind-address 参数值为 0.0.0.0 或者具体的 IP 地址以便允许来自不同主机之间的通信请求。 #### 处理 sock 文件位置差异 针对上述提及的 ERROR 2002 错误码,在 Mac OS X 上经常是因为 mysqld 和客户端之间约定俗成使用的 socket 文件路径并不一致造成的。可以通过修改 ~/.my.cnf 添加如下选项指向实际存在的 socket 文件位置从而修复此状况: ```ini [client] socket=/usr/local/var/mysql/mysql.sock ``` 另外一种方式是在每次启动之前手动创建软链接让两者保持同步: ```bash ln -s /usr/local/var/mysql/mysql.sock /tmp/mysql.sock ``` #### 检查 SELinux/AppArmor 设置(适用于Linux) 安全模块如 SELinux 或 AppArmor 对进程的行为有着严格的控制策略,默认的安全上下文定义可能会干扰 MySQL 的正常运作流程。因此有必要临时禁用它们看看是否能够解除故障现象的发生: ```bash setenforce Permissive # For SELinux systems aa-disable /etc/apparmor.d/usr.sbin.mysqld # For AppArmor systems ``` 当然这只是作为初步测试手段之一,长期来看还是推荐深入研究官方文档了解如何合理配置这两个防护机制使之既不影响数据库性能又能保障系统的安全性。 #### 查看详细的错误日志 最后但同样重要的是要仔细阅读位于 `$DATADIR/hostname.err` 下的日志条目,这里往往包含了最直观也最有价值的信息用于指导后续的操作方向。
评论 12
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值