标题: Can't connect to local MySQL server through socket [打印本页] 作者: 987sahala 时间: 2010-2-25 18:17 标题: Can't connect to local MySQL server through socket 搞了几天了不能解决，本人菜鸟一个，各位帮帮忙啊~
情况是这样的，我的论坛www.gdpuzs.com突然出现Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)这个错误，我没有修改过任何论坛配置文件。所以肯定是MYSQL的问题。然后我登陆到Kloxo一看，原来是日志和网站统计空间占满了空间。于是就联系第九主机删除了日志。本以为没事了，但是情况还是这样。现在最关键的是，MYSQL不能完整导出数据，每次都差几M,用帝国备份王又经常提示与MYSQL断开连接。各位兄弟帮帮忙啊~~~作者: dream26 时间: 2010-2-25 18:18
就是數據不完整?作者: 987sahala 时间: 2010-2-25 18:23
对。数据库有99M，但是备份出来只有80多M作者: Administrator 时间: 2010-2-25 18:25
提示: 作者被禁止或删除 内容自动屏蔽作者: 987sahala 时间: 2010-2-25 18:55
好的~谢谢。我试试作者: cpuer 时间: 2010-2-26 18:22 标题: 回复 1# 的帖子 看下mysql日志。作者: 987sahala 时间: 2010-2-27 09:42
MYSQL 日志里全不断重启，C大帮我看看是什么原因吧。。。
我是新手，不懂啊。论坛挂了好几天了。
Number of processes running now: 0
100227 00:29:01 mysqld restarted
100227 0:29:01 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100227 0:29:01 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100227 0:29:01 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.77' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
100227 0:29:52 - 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=6291456
read_buffer_size=262144
max_used_connections=1
max_connections=64
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 38912 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8c631f8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb64fb858, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x818d468
0x8274ff3
0x81eebbe
0x81f1378
0x81f2269
0x81fa2d9
0x81fac8d
0x81a6ec2
0x81ab2cd
0x81ab826
0x81ad808
0xb7d5873b
0xb7b78cfe
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8c9b648 = SELECT p.*, m.uid, m.username, m.groupid, m.adminid, m.regdate, m.lastactivity, m.posts, m.threads, m.digestposts, m.oltime,
m.pageviews, m.credits, m.extcredits1, m.extcredits2, m.extcredits3, m.extcredits4, m.extcredits5, m.extcredits6,m.extcredits7, m.extcredits8, m.email, m.gender, m.showemail, m.invisible, mf.nickname, mf.site,
mf.icq, mf.qq, mf.yahoo, mf.msn, mf.taobao, mf.alipay, mf.location, mf.medals,
mf.sightml AS signature, mf.customstatus, mf.spacename
FROM cdb_posts p
LEFT JOIN cdb_members m ON m.uid=p.authorid
LEFT JOIN cdb_memberfields mf ON mf.uid=m.uid
WHERE p.tid='7671' AND p.invisible='0' ORDER BY dateline LIMIT 10, 10
thd->thread_id=10
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Number of processes running now: 0
100227
00:29:52 mysqld restarted
100227
对了。phpmyadmin 状态里面 有一段话
1 On a busy server, the byte counters may overrun, so those statistics as reported by the MySQL server may be incorrect.作者: cpuer 时间: 2010-2-28 12:01
100227 0:29:52 - 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=6291456
read_buffer_size=262144
max_used_connections=1
max_connections=64
threads_connected=1