Remember to help users solve the problem caused by illegal KILL MySQL service

Shenzhen-Wanderer 9:55:26 The villagers ask you a thing

Shenzhen-Wanderer 9:55:29 Mysql.sock lost, MySQL Qibulai, how do you solve?

Bell 10:04:41 This file is not dynamically generated?

Bell 10:04:53 Deleted, automatically generated when the service is started

Shenzhen-Wanderer 10:12:02 It's not starting now.

Shenzhen-Wanderer 10:12:15 Tried a variety of methods Qibulai

A netizen to find me, said is using MySQL prompt the following error:

ERROR 2002 (HY000): Can ' t connect to local MySQL server through socket '/var/lib/mysql/mysql.sock ' (2)

The first thing is to look at the service is not normal:

Netstat-tunlp|grep 3306

That there is no service process

Say you start the service look

/etc/init.d/mysql start

Tips are as follows:

Starting MySQL ... error! The server quit without updating PID file (/var/lib/mysql/localhost.localdomain.pid)

According to the usual thinking is, first look at the/var/lib/mysql directory of the genus group, permissions, see everything normal. Looking at the disk space again, Innode is completely normal.

Bell 10:17:54 Before the breakdown, you did everything.

Shenzhen-Wanderer 10:18:16 Do the permission settings

Bell 10:18:27 I'll take a look at the specific hair. Bell 10:18:35 Did you restart it when you were done? Shenzhen-Wanderer 10:20:55 Delete from mysql.user where password= '; Update user set host= ' IP ' where user= ' root ' and host= '% ';  Select User,host,password from Mysql.user; Service MySQL Restart Bell 10:21:53 Once you have set the permissions, you do not have to restart the service. At this point, it must be the kill MySQL service, and then to the log, as follows:

2016-12-01 15:13:01 0 [Warning] TIMESTAMP with implicit the 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) is 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

After reading the log, communicate again that it was the kill MySQL service, and not even once. And all the database server has done so, a cold sweat ah!!! I said what else to do, he said also changed the configuration file, added an event, did not control it, simply did the following actions:

MV My.cnf My.cnf.ori
/etc/init.d/mysql start

Haha, a long-lost start success hints came out finally. Then let him log in to look at the data right, look at the next no problem.

Summarize:

Finally through and his communication, the same environment, the same database version, the same configuration, only this one does not start up. After analysis and judgement, the reason for this failure is: Kill MySQL service process, illegal shutdown service caused this fault. According to the old driver experience, the random Kill database service process, especially kill-9, will cause a variety of database failures! Everyone warning it!!!

This article is from the cloud computing and Big Data blog, so be sure to keep this source http://linuxzkq.blog.51cto.com/9379412/1878839

Remember to help users solve the problem caused by illegal KILL MySQL service