收到数据库连不上的信息后,登录到服务器上,确认了cpu、内存和磁盘是否正常
首先查看了数据库进程,看到有两个进程
尝试重启了一次数据库,启动失败,进程依然有两个,且pid在不断变化。
遂停止了连接的应用,尝试重启数据库,查看端口启动之后,启动应用报错,Navicat连接时而正常时而不正常。如此反复尝试重启了N次之后,意识到这次重启大法大概不顶用了。
根据以往的经历,越是这时候越不能慌。于是假装淡定地看日志,应用启动日志,mysql错误日志,系统日志。
根据messages日志发现,mysql在不断重启。。。
在判断了mysql在不断地重启之后,这也就是为什么会出现两个mysql进程的原因了。
于是接着看mysql的错误日志,感觉日志会很大,所以在vi之前事先判断了下大小,结果有32G。。。(此处无图。。。找不到了)要是一开始就用vi,后背发冷。。。错误日志文件太大,内容肯定是难以看到了,只能想法子看后面的。所以用echo清空了mysql.log,让实例输出新的日志。
在新的日志打出来后,感觉应该是参数设置大了。
于是就开始调参。但是这个地方,在调参之前未对原有参数进行备份,这个在以后需要注意。
在调整了一番以下几个参数之后,启动依然还是相同的错误。
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 170102412 K bytes of memory
无奈之下,只能找百度了,拷贝了系统日志中的mysql错误
May 8 21:02:39 mzgarm systemd: mysqld.service: main process exited, code=exited, status=2/INVALIDARGUMENT
May 8 21:02:39 mzgarm systemd: Unit mysqld.service entered failed state.
May 8 21:02:39 mzgarm systemd: mysqld.service failed.
最后发现这是一次崩溃。
于是在my.cnf配置文件中加入 innodb_force_recovery = 1参数,然后重启MySQL,从1-6逐一叠加,直到能正常启动为止,正常启动后把 innodb_force_recovery 设置为0或者注释掉,再重启MySQL。
注意事项:
- 首要查看日志,根据日志做出下一步的操作判断;
- 发现崩溃,一定要先确认数据是否有备份;
- 如果不是万不得已,请再三考虑是否使用 #innodb_force_recovery = 1;一定要时刻关注日志输出情况。
参考内容:
https://www.jb51.net/article/66951.htm
https://bugs.mysql.com/bug.php?id=91056
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-18.html
https://support.oracle.com/knowledge/Oracle%20Database%20Products/2249231_1.html
附:可能出现的附加问题
2020-06-09T02:13:20.807662Z 0 [Note] InnoDB: 5.7.19 started; log sequence number 3144939669386
2020-06-09T02:13:20.808445Z 0 [Note] InnoDB: Loading buffer pool(s) from /home/mysql/DBdata/ib_buffer_pool
2020-06-09T02:13:20.808669Z 0 [Note] Plugin 'FEDERATED' is disabled.
2020-06-09T02:13:20.808972Z 0 [Note] InnoDB: Buffer pool(s) load completed at 200609 10:13:20
2020-06-09T02:13:20.822589Z 0 [Note] Server hostname (bind-address): '*'; port: 8300
2020-06-09T02:13:20.822660Z 0 [Note] IPv6 is available.
2020-06-09T02:13:20.822676Z 0 [Note] - '::' resolves to '::';
2020-06-09T02:13:20.822681Z 0 [Note] Server socket created on IP: '::'.
2020-06-09T02:13:20.822735Z 0 [ERROR] Unix socket lock file is empty /var/lib/mysql/mysql.sock.lock.
2020-06-09T02:13:20.822743Z 0 [ERROR] Unable to setup unix socket lock file.
2020-06-09T02:13:20.822746Z 0 [ERROR] Aborting
2020-06-09T02:13:20.822782Z 0 [Note] Binlog end
MySQL日志中如果出现上述内容,可能是socket文件有问题,删除mysql.sock.lock文件,然后重启mysql服务即可。