记录一个Mysql服务kill后重启失败的解决方法

问题描述

起因是要通过Canal把数据从Mysql同步到其他地方。然后在实施时，发现生产环境Mysql的binlog并没有打开。修改my.cnf配置后，进行Mysql restart一直失败，报错是ibdata1文件无法进行Lock，试过网上各种方法还是无法重启Mysql(确实能通过cp -a方式解除锁定，但是后续还有很多其他数据文件无法进行Lock)，Stop Mysql服务也是同样因为这个原因失败。

最终决定冒险赌一把(毕竟数据文件还在，还有恢复的方案)。直接kill Mysql，然后就再也启动不了mysql服务了。(╯‵□′)╯︵┻━┻。

启动失败的报错，明确的ERROR信息只有Too many arguments

但是哪怕把启动参数修改的只剩下基础的几个baseDir，dataDir等也无法启动。(估计真实的报错原因并没有在日志里显示出来)

解决方案：

注：不一定针对你的场景有效，本人遇到的是data文件完全没有损坏的情况，请谨慎决定是否尝试这种方式。

在机器上重新下载部署一个和无法启动mysql版本相同的mysql(本人采用tar.gz解压的方式)，在执行mysql初始化的时候，例：

mysqld --initialize --user=mysql --basedir=/soft/mysql --datadir=/soft/mysql/data

dataDir先指向空文件夹，baseDir指向当前安装mysql的目录(就如第一次安装mysql的步骤)。

等初始化结束后，先尝试启动，正常启动后，再关闭当前mysql服务。

修改配置文件(Linux下默认是/etc/my.cnf)中的dataDir和baseDir指向无法启动的mysql目录原本使用的路径，lock文件不要指向原先的路径。配置完成后，再次启动即可，什么都跟原来的一样。 

最后，kill掉数据库真的很危险，能restart就不要乱kill，如果没有准备好kill后出现故障的恢复方案，不要像我一样作死呀。在kill前，尽可能先备份数据。