mysql没有生成mysqld.sock是什么原因？要怎么解决？紧急求助

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 4162 天前的主题，其中的信息可能已经有所发展或是发生改变。

问题产生愿意在 /t/74310

机房停电，恢复之后mysql无法启动，不得已重新卸载安装mysql，但是发现网站经常出现无法连接数据库的错误，打开debug之后提示如下：
Warning: mysql_connect(): [2002] No such file or directory (trying to connect via unix:///var/run/mysqld/mysqld.sock) in /srv/www/xxxx.com/public_html/wp-includes/wp-db.php on line 1143 Warning: mysql_connect(): No such file or directory in /srv/www/xxxx.com/public_html/wp-includes/wp-db.php on line 1143

然后我去/var/run/mysqld/查看，确实没有mysqld.sock这个文件，并且当初停电之后我看这个目录里也没有这个文件，现在要怎么解决啊？

mysqld

MySQL

17 条回复 • 1970-01-01 08:00:00 +08:00

xingxiucun

2013-07-02 16:10:46 +08:00

启动了没 mysqld

nonozone

2013-07-02 16:26:03 +08:00

@xingxiucun 启动了

xmbaozi

2013-07-02 16:30:18 +08:00

一般碰到这种情况你会气死的，因为。。。
这个贴的id是 /t/74444 哈哈

54dev

2013-07-02 17:10:39 +08:00

没启动

54dev

2013-07-02 17:10:53 +08:00

@nonozone 如果启动了，就看一下日志

nonozone

2013-07-02 17:12:33 +08:00

@54dev 很奇怪啊，mysql没有输入log，log文件是空的。

lululau

2013-07-02 17:47:56 +08:00

最简单的解决办法是改成走 HTTP，把 MySQL 连接字符串里的地址改成 127.0.0.1 或者其它IP

msg7086

2013-07-02 18:07:11 +08:00

直接sudo mysqld看看报错不

nonozone

2013-07-02 18:14:18 +08:00

root@debian /home# mysqld
130702 3:14:54 [Note] Plugin 'FEDERATED' is disabled.
130702 3:14:54 InnoDB: Initializing buffer pool, size = 8.0M
130702 3:14:54 InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 0 41789036
130702 3:14:54 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 42340688
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 0 372480
130702 3:14:55 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Cleaning up trx with id 0 328576
130702 3:14:55 InnoDB: Rollback of non-prepared transactions completed
130702 3:14:55 InnoDB: Started; log sequence number 0 42340688
130702 3:14:55 [Note] Event Scheduler: Loaded 0 events
130702 3:14:55 [Note] mysqld: ready for connections.
Version: '5.1.66-0+squeeze1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
130702 3:14:56 InnoDB: Assertion failure in thread 2949757808 in file ../../../storage/innobase/fsp/fsp0fsp.c line 3 341
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:14:56 UTC - mysqld got signal 6 ;
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=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 345939 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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...
stack_bottom = 0 thread_stack 0x30000
mysqld(my_print_stacktrace+0x2d) [0xb753e8ad]
mysqld(handle_fatal_signal+0x4a4) [0xb7322e64]
[0xb6f6a400]
/lib/i686/cmov/libc.so.6(abort+0x182) [0xb6c8dbb2]
mysqld(fseg_free_step_not_header+0x203) [0xb742ccf3]
mysqld(+0x513a20) [0xb749ba20]
mysqld(+0x513f13) [0xb749bf13]
mysqld(trx_purge_fetch_next_rec+0x85) [0xb749c055]
mysqld(row_purge_step+0x42) [0xb747b912]
mysqld(que_run_threads+0x5b0) [0xb7466ea0]
mysqld(trx_purge+0x385) [0xb749a035]
mysqld(srv_master_thread+0xf80) [0xb7490330]
/lib/i686/cmov/libpthread.so.0(+0x5955) [0xb6f50955]
/lib/i686/cmov/libc.so.6(clone+0x5e) [0xb6d2c1de]
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.

11138

2013-07-02 19:23:47 +08:00

很明显啊，MySQL启动后又崩溃了。

MyISAM类型的数据库可以直接复制转移。

试一下在 my.cnf 中 [mysqld] 字段写入
innodb_force_recovery = 6

看看能不能启动，如果能，用 mysqldump 导出数据库，删除了数据库重建并导入。

另外，试一下换一下软件版本。

jpuyy

2013-07-02 21:13:15 +08:00

先保护好数据再操作别的

kqz901002

2013-07-02 23:08:09 +08:00

mysql.start

nonozone

2013-07-02 23:51:53 +08:00

现在已经用笨办法将数据转移到另外一台主机了，只是想知道这个问题要如何解决。

asher

2013-07-02 23:53:00 +08:00

我也遇到一回这情况。
然后问题是空间满了。
生成不了。

nonozone

2013-07-03 08:29:49 +08:00

@asher 哪里的空间？磁盘空间，这个我倒是不会。

julyclyde

2013-07-03 10:53:13 +08:00

@lululau 你确定你真懂mysql？？

lululau

2013-07-03 11:32:31 +08:00

@julyclyde 写错了，TCP写成HTTP了，不过写对了估计这个傻逼也看不懂