问题描述
起因是要通过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前,尽可能先备份数据。