最近開發人員那邊總說他們的程序連接一臺指定服務器的時候出現閃斷的現象,有連接失敗的日志生成.于是就登陸到這臺機器上探查個究竟,看了下mysql的錯誤日志,發現有mysql崩潰的現象,數據目錄下面生成好多的bin文件,錯誤日志里面的內容如下:

090922? 1:10:39 - mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

We will try our best to scrape up some info that will hopefully help diagnose

the problem, but since we have already crashed, something is definitely wrong

and this may fail.

key_buffer_size=16777216

read_buffer_size=262144

max_used_connections=61

max_threads=151

threads_connected=50

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133312 K

bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

這里只貼出來了一部分的內容,錯誤日志里面有大量相同的錯誤,看來mysql的崩潰和這個有很多的關系,于是就在網上搜下原因,找了好久都沒有找到解決的方法,最后去了mysql的官方網站溜達了下,發現有個人提出來了一個方法就是通過ulimit -a 看相關的信息,主要是看 open file這項,于是就在本數據庫服務器看了下,數據是1024,然后用ulimit -n 進行了修改 使其改的大一些,但是發現有些問題,我下次登錄這臺服務器的時候發現這個選項有變會到了1024,很是奇怪.于是又找了找其他的方法,下面方法是比較完美的:

#vi /etc/security/limits.conf

在下面添加如下的一行

* -? nofile 65536

#vi /etc/pam.d/login

在下面添加如下的一行

session??? required???? /lib/security/pam_limits.so

OK,然后再用ulimit -a 看下 發現已經改過來了,再沒有返回到1024了,通過一下午的檢測,再沒有發現mysql的崩潰,繼續檢測,看近2天還會不會發生崩潰了,要是不是就是這個原因導致的問題.

總結

以上是生活随笔為你收集整理的mysql崩溃_mysql崩溃原因分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。