现象,
通过查看 日志,
可以看到,这里经过了10分钟,MySQL才进行了第二次尝试启动,
在这里卡了10分钟之久,
查看, /etc/my.cnf
[root@bogon ~]# cat /etc/my.cnf
symbolic-links
是否支持符号链接，即数据库或表可以存储在my.cnf中指定datadir之外的分区或目录，为0不开启
sql_mode = STRICT_TRANS_TABLES
“STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER”
sql_mode 模式，定义了你MySQL应该支持的sql语法，对数据的校验等等，限制一些所谓的‘不合法’的操作
对于STRICT_TRANS_TABLES，MySQL将非法值转换为最接近该列的合法值并插入调整后的值。
“NO_ENGINE_SUBSTITUTION”，表示不进行引擎替换.
但,神奇的是,我把这两货删除之后,重启服务器,MySQL秒启动,一点也不卡了.
回过头,咱们再来研究日志,
这是我重启服务器的日志描述,normal shutdown 正常关闭MySQL
到这里,出现了 [Warning] 但不是ERROR,所以忽略继续往下看
到这里,出了3个ERROR, 但没卡住,还在继续往下走,
注意这里,02到12,卡了10分钟,
然后没停顿继续往下走,
虽然这里又出了3个 [Warning] ,但没卡继续往下走
直接启动成功,
这里拦一下 一个循环结束 接着分析 下面的日志
这里，在下一个循环开始之前，
一个新的重启,
又出现了3个 [Warning] ,但没卡,继续往下走,
一点也没卡,直接秒起,
第二个循环的 服务器重启时间是:15:03:00，数据库就位的时间是： 15:03:17，时间采用了１７０毫秒，
和刚才的 １０分钟比起来，天差地别．
这就是 ／ｅｔｃ／ｍｙ．ｃｎｆ 文件影响的ＭｙＳＱＬ 启动
Ｆｅｂｒｕａｒｙ ｔｈｅ 01st 2022 tuesday
补充,
重启服务器没问题,但是关闭服务器等半小时再开机,
就又出现了之前的问题,卡在
mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
这里,然后过了10分钟才又开始执行下面的语句
mysqld_safe Logging to '/var/log/mysqld.log'.
卡在它俩中间了,
于是,继续研究,
去看 交给 chkconfig 管理的 mysqld 的内容,
[root@bogon ~]# cd /etc/rc.d/init.d
[root@bogon init.d]# ll
[root@bogon init.d]# cat mysqld
我设置的 mysqld 的启动顺位是3,
但, [Unit] 写明了,要在 network 之后启动,
所以还要去看一下 network 的启动顺位是多少,
[root@bogon init.d]# cat network
可以看到,network 的启动顺位是 10,
所以,需要将 mysqld 的启动顺位调整到 network 之后,
[root@bogon init.d]# vi mysqld
调整完毕,保存退出,
再关机等待一段时间后,开启服务器,看结果,
还是不行,
去查看
MySQL 当前状态
[root@bogon ~]# systemctl status mysqld
可以看出,MySQL 启动的时候,是要去load /usr/lib/systemd/system/mysqld.service它的,
去看看它里面都有啥,
[root@bogon ~]# cd /usr/lib/systemd/system/
[root@bogon system]# ll |grep mysql
打开看看
[root@bogon system]# cat mysqld.service
有一行这个,600秒不就是10分钟嘛,不正好是卡住的时间长度么(mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended),
既然我不知道问题出在哪里,
要不我就给这个时间减少点,这样会不会能快点启动呢?
着手实验,
[root@bogon system]# vi mysqld.service
改成 6 秒,保存退出,关机 等待一段时间,再开机,看看效果.
可以了,
不用等10分钟以上了.
但不知道,问题是不是彻底解决了,
需要在以后的使用中验证,
February the 01st 2022 tuesday
