mysql启动失败又一例

Posted Digital_life

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql启动失败又一例相关的知识,希望对你有一定的参考价值。

搭的wordpress报错:

后台用的mysql,之前也崩过,原因是虚拟内存耗尽,通过增加swap空间最终让数据重新启动。

但仅过一晚上,数据库再次崩溃。看来要查一查是什么程序耗尽资源。

执行top,切到VIRT列,以虚拟内存使用量进行排序。

root@ns-xxzx-svr:/var/log/mysql# top
top - 10:51:24 up 81 days, 19:52, 2 users, load average: 1.47, 1.14, 0.89
Tasks: 774 total, 3 running, 770 sleeping, 0 stopped, 1 zombie
%Cpu(s): 1.8 us, 32.4 sy, 0.0 ni, 36.4 id, 28.0 wa, 0.0 hi, 1.4 si, 0.0 st
KiB Mem: 1026284 total, 941336 used, 84948 free, 188 buffers
KiB Swap: 3952632 total, 3952632 used, 0 free, 4152 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9065 root 20 0 328m 50m 0 S 2.0 5.0 28:07.37 java
26155 hyang0 20 0 170m 24m 660 S 0.0 2.4 0:03.38 check-new-relea
28176 hyang0 20 0 170m 24m 624 S 0.0 2.4 0:04.07 check-new-relea
26782 hyang0 20 0 170m 23m 516 S 0.0 2.3 0:03.35 check-new-relea
25522 hyang0 20 0 169m 23m 652 S 0.0 2.3 0:04.92 check-new-relea
27531 hyang0 20 0 170m 23m 704 S 0.0 2.3 0:05.11 check-new-relea
28832 hyang0 20 0 169m 23m 516 S 0.0 2.3 0:07.84 check-new-relea
19835 hyang0 20 0 170m 22m 604 S 0.0 2.3 0:03.34 check-new-relea
20530 hyang0 20 0 170m 22m 704 S 0.0 2.2 0:03.81 check-new-relea
24742 hyang0 20 0 168m 21m 848 S 0.0 2.2 0:04.99 check-new-relea
11952 hyang0 20 0 170m 21m 856 S 0.0 2.1 0:03.28 check-new-relea
23943 hyang0 20 0 170m 21m 748 S 0.0 2.1 0:04.97 check-new-relea
6850 hyang0 20 0 168m 20m 876 S 0.0 2.0 0:03.00 check-new-relea
17144 hyang0 20 0 170m 19m 648 S 0.0 1.9 0:03.24 check-new-relea
18423 hyang0 20 0 170m 19m 640 S 0.0 1.9 0:03.23 check-new-relea
3105 hyang0 20 0 106m 18m 1796 S 41.5 1.9 1:40.46 check-new-relea
2387 hyang0 20 0 170m 18m 624 S 0.0 1.9 0:03.18 check-new-relea

发现有几十个check-new-relea的进程,每个占用170多兆虚拟内存。再查看swap使用量:

root@ns-xxzx-svr:/var/log/mysql# sudo swapon  -s
Filename                                Type            Size    Used    Priority
/dev/sda5                               partition       1046524 1046524 -1
/dev/sdd1                               partition       2906108 2906108 -2

像上次一样,已经耗尽。在网上也找到类拟的问题:

下面就是处理这些进程了。用pstree, pgrep查找这些进程,确认不会误杀,pkill干掉这些进程。

root@ns-xxzx-svr:~# pgrep check-new- -l
669 check-new-relea
1091 check-new-relea
1762 check-new-relea
1977 check-new-relea
2197 check-new-relea
2387 check-new-relea
2715 check-new-relea
2937 check-new-relea
3030 check-new-relea
3395 check-new-relea
3635 check-new-relea
3722 check-new-relea

root@ns-xxzx-svr:~# pkill check-new-
root@ns-xxzx-svr:~# pgrep check-new- -l
root@ns-xxzx-svr:~#

再次通过top 和 swapon工具查看资源情况,已经都释放了。mysql 再次复活。

root@ns-xxzx-svr:/var/log/mysql# sudo swapon  -s
Filename                                Type            Size    Used    Priority
/dev/sda5                               partition       1046524 113876  -1
/dev/sdd1                               partition       2906108 144480  -2
root@ns-xxzx-svr:/var/log/mysql# /etc/init.d/mysql start
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql start

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start(8) utility, e.g. start mysql
mysql start/running, process 5009
root@ns-xxzx-svr:/var/log/mysql#

 

以上是关于mysql启动失败又一例的主要内容,如果未能解决你的问题,请参考以下文章

MySQL MHA切换失败一例

ubuntu下处理mysql无法启动故障一例

又一例 select for update 的悲观锁使用所引发的血案

一例mysql主从数据库,从库宕机后无法启动的解决方案

又一例掉了3块盘的服务器数据恢复成功了

popBackStack导致一次又一次调用片段的oncreateView