docker 自带重启策略,restart有三个参数：no,on-failure,always
一般选择on-failure,也就是非正常宕机都重启,手动停止不重启.
①no为默认值,表示容器退出时,docker不自动重启容器
最近遇到个比较有意思的问题,服务器宕掉后无法启动,想了好多办法,虽然解决了问题,数据没有丢失,但是没有按照自已的思路来,未免还是有些不甘.遇到问题不能慌,尤其是线上的环境,更不能紧张,心理素质对DBA来说也是一项挑战,可能你的手一抖就会导致多少人无法正常使用业务,如果你没有把握,请先把现场环境备份后再进行操作,避免数据的二次损坏,下面壹基比小喻说一下大概的思路吧.
①检查是否有备份,如果备份存在,binlog存在,那么万事大吉,一切都有挽回的余地,慢慢来搞,只要你基础扎实,数据还原只是时间的问题.
在my.cnf中[mysqld]下加上以下配置,采用强制恢复机制,看是否能够启动
[mysqld]
innodb_force_recovery=1
当innodb_force_recovery被设置为大于0的时候 ,会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务,类似于windows系统下的安全模式.以下这段引于其它地方,具体地址不太清楚了,也可以从官方文档中找到.
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页,也让服务器运行着；试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页,这样有助于转储表.
阻止主线程运行,如果崩溃可能在净化操作过程中发生,这将阻止它.
恢复后不运行事务回滚.
也阻止插入缓冲合并操作.如果你可能会导致一个崩溃.最好不要做这些操作,不要计算表统计表.
启动数据库之时不查看未完成日志：InnoDB把未完成的事务视为已提交的.
不要在恢复连接中做日志前滚.
数据库不能另外地带着这些选项中被允许的选项来使用.作为一个安全措施,当innodb_force_recovery被设置为大于0的值时,InnoDB阻止用户执行INSERT, UPDATE或DELETE操作.
关于上面进行逻辑备份也可能会遇到问题,可能会备份失败,如果出错,建议先按库一个一个的备份,到哪个库出错后,再按照当前库的表一个一个备份,表出错根据表中主键一点一点备份,最终将大部分数据导出.如果你的数据不重要,可以容忍丢失,那么可以当我说的都是废话了.
查看错误日志,看没有提示因为某个表的原因而导致启动不了,可以先把损坏的表的ibd文件先从数据目录mv走,再试着启动,在数据已经恢复后,我把当时错误的文件拿到本地,做了测试,把几个报错的ibd文件mv走后,数据库就可以正常启动了,但是mv走的这几个表数据会丢失.怎么把这个表的数据弄回来呢,曾想过用在线表空间传输,但是.cfg文件却没有,这种方法没有行通.后来用Percona Data Recovery Tool for InnoDB工具进行数据恢复,关于这个工具的介绍与操作,网上一大堆,我就不详细说明了.
以上就是土嘎嘎小编为大家整理的mysql宕机怎么办相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！