核心内容摘要
最美情侣免费视频播放电视剧推荐,浪漫爱情故事,高清在线观看,精彩...
之前我们进行MySQL
4的部署可以参考历史文章别再yum装MySQL了教你大厂级部署法部署MySQL
4实测无坑可无脑照抄最后的部分我们使用服务的方式进行数据库的启停操作今天有小伙伴在部署的时候出现了诡异的一幕启动的时候一直没有返回据说已经试了2天了其他版本都正常当前这个集群一直异常一度怀疑是服务器问题不禁想起一位故人。
再一查MySQL服务明明已经启动可以正常连接和使用但systemctl却报告启动超时。
经过远程查看后发现了问题的根源。
今天我们就来复现一下此问题也给其他小伙伴参考。
正常情况用我们之前部署的MySQL
4举例部署的mysqld服务步骤如下
配置服务创建服务文件 /etc/systemd/system/mysqld.service添加如下内容[Unit]DescriptionMySQL ServerAfternetwork.targetAftersyslog.target[Service]UsermysqlGroupmysqlTypenotifyExecStart/usr/local/mysql
4/bin/mysqld --defaults-file/data/mysql/mysql3306/etc/my.cnfTimeoutSec300Restarton-failureRestartPreventExitStatus1PrivateTmpfalse[Install]WantedBymulti-user.target
重载服务systemctl daemon-reloadsystemctl enable mysqld
启动数据库systemctl start mysqldsystemctl status mysqld启动数据库后数据库日志文件如下数据库也能正常登录
本次异常情况
异常现象前面的配置过程都一样启动服务时一直没返回启动结束直到达到超时时间上面脚本里可以看出配置的超时时间是TimeoutSec300,即300s然后报错[rootalidb ~]# systemctl start mysqldJob for mysqld.service failed because a timeout was exceeded. See systemctl status mysqld.service and journalctl -xe for details.查看服务状态显示starting[rootalidb ~]# systemctl status mysqld.service● mysqld.service - MySQL Server Loaded: loaded (/etc/systemd/system/mysqld.service; bad; vendor preset: disabled) Active: activating (start) since Mon
20:08:12 CST; 4min 24s ago Main PID: 19413 (mysqld) CGroup: /system.slice/mysqld.service └─19413 /usr/local/mysql
7/bin/mysqld --defaults-file/data/mysql/mysql3307/etc/my.cnfFeb 02 20:08:12 alidb systemd[1]: Starting MySQL Server...查看数据库进程数据库进程确实正常运行着。
且可以正常访问日志也显示正常虽然看上去是不影响正常使用但是启动时一直等待的状态无法直接判断是否正常启动完毕了。
原因分析经过对比发现这位小伙伴用的是MySQL
7原因是给原先的单节点的主库加从节点从数据库的日志可以看出MySQL
4和MySQL
7 有着细微差别即反馈的信号不太一样。
因此针对MySQL
7 的版本我做了一下调整调整后的服务配置如下[Unit]DescriptionMySQL ServerAfternetwork.targetAftersyslog.target [Service]UsermysqlGroupmysqlTypeforkingExecStart/usr/local/mysql
7/bin/mysqld --defaults-file/data/mysql/mysql3307/etc/my.cnf --daemonizeTimeoutSec300Restarton-failureRestartPreventExitStatus1PrivateTmpfalse [Install]WantedBymulti-user.target这次秒回结果如下其中的关键调整点就如下2个Typeforking适配MySQL
7的工作模式--daemonize参数确保MySQL以守护进程模式运行如果更严谨一点可以考虑再加上PIDFile参数便于找到对应的进程号。
结语MySQL服务启动超时问题看似简单实则涉及systemd工作机制、MySQL版本特性等多方面知识。
作为一名DBA理解这些底层原理至关重要。
如果大家下次遇到类似问题不妨先检查MySQL版本与service配置的匹配性这可能会帮你节省大量排查时间。
运维之道在于深入理解系统运作机制而非仅仅记忆解决方案。
你是否在MySQL运维中遇到过其他有趣的问题欢迎在留言区分享你的经历和解决方案关注微信公众号「数据库干货铺」