标签：mysql
深圳—游子 9:55:26 老乡 请教你个事 |
深圳—游子 9:55:29 mysql.sock 丢失，mysql启不来，请问大家是怎么解决的？ |
Bell 10:04:41 这个文件不是动态生成的么 |
Bell 10:04:53 删除了，启动服务时会自动产生的 |
深圳—游子 10:12:02 现在启动不了 |
深圳—游子 10:12:15 试了各种方法启不来 |
一网友找我，说是使用MySQL提示如下错误：
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (2)
首先想的是看下服务正常不：
netstat -tunlp|grep 3306
说是没有服务进程
说你启动服务看看
/etc/init.d/mysql start
提示如下：
Starting MySQL... ERROR! The server quit without updating PID file (/var/lib/mysql/localhost.localdomain.pid)
按照以往的正常思路是，首先看看/var/lib/mysql目录的属主属组，权限,查看一切正常。又看了下磁盘空间，innode也完全正常。
Bell 10:17:54 在这故障之前你做了什么都 |
深圳—游子 10:18:16 做了权限设置 |
Bell 10:18:27 具体的发过来我看下 Bell 10:18:35 做完后重启了吗 深圳—游子 10:20:55 这时就想到肯定是KILL MySQL服务了，于是要来了日志，如下： |
2016-12-01 15:13:01 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp
server option (see documentation for more details).
2016-12-01 15:13:01 0 [Note] /usr/sbin/mysqld (mysqld 5.6.28) starting as process 19651 ...
2016-12-01 15:13:01 19651 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-12-01 15:13:01 19651 [Note] InnoDB: The InnoDB memory heap is disabled
2016-12-01 15:13:01 19651 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-12-01 15:13:01 19651 [Note] InnoDB: Memory barrier is not used
2016-12-01 15:13:01 19651 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-12-01 15:13:01 19651 [Note] InnoDB: Using Linux native AIO
2016-12-01 15:13:01 19651 [Note] InnoDB: Not using CPU crc32 instructions
2016-12-01 15:13:01 19651 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-12-01 15:13:01 19651 [Note] InnoDB: Completed initialization of buffer pool
2016-12-01 15:13:01 19651 [Note] InnoDB: Highest supported file format is Barracuda.
2016-12-01 15:13:01 19651 [Note] InnoDB: 128 rollback segment(s) are active.
2016-12-01 15:13:01 19651 [Note] InnoDB: Waiting for purge to start
2016-12-01 15:13:02 19651 [Note] InnoDB: 5.6.28 started; log sequence number 180311887
2016-12-01 15:13:02 19651 [ERROR] /usr/sbin/mysqld: unknown variable ‘sql_modcheduler=ONi_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
‘
2016-12-01 15:13:02 19651 [ERROR] Aborting
看完日志，再次沟通得知，果然是KILL MySQL服务了，而且不至一次。并且所有的数据库服务器都这样操作过，冒冷汗啊！！！我说还做什么了，他说还改了配置文件，加了一条EVENT ，没管它，索性做了如下操作：
mv my.cnf my.cnf.ori
/etc/init.d/mysql start
哈哈，久违的启动成功提示出来了终于。之后让他登录上去看下数据对不对，看了下没有问题。
总结：
最后经过和他的沟通，同样的环境，同样的数据库版本，同样的配置，只有这一台启动不起来。经过分析判断得出，此次故障的原因为：kill MySQL服务进程，非法关闭服务导致本次故障。根据老司机经验，随便kill数据库服务进程，特别是kill -9，是会导致各种各样的数据库故障的！大家引以为戒吧！！！
本文出自 “云计算与大数据” 博客，请务必保留此出处http://linuxzkq.blog.51cto.com/9379412/1878839
标签：mysql
原文地址：http://linuxzkq.blog.51cto.com/9379412/1878839
