Mysql故障处理2则
手下做mysql复制,做好了之后发现read master position在不断移动,但是数据就是不同步。其实稍微理解一点mysql复制中server-id的功能就知道怎么回事了,马上打开my.cnf一看,果然有2个server-id。去掉一个自然就ok了。这个问题判断起来还是要靠经验,不过做事情仔细就不会有这个故障了。。。。
晚上回家,在地铁收到值班人员的电话,计费系统出现大量sql堵塞,读的数据库同步缓慢。
到家里上vpn分析了监控系统的日志。查看了系统当前的情况,定位了问题sql,开发加了一句不必要的排序造成了sql走的索引全扫描,100w的表么并发一大当然死掉了,而且还是句update,直接导致串行工作的复制进程在读的机器上前进缓慢,这个情况就是oracle来也是一样死,还是开发牛比啊。。。。
马上让应用停止和该表有关的应用,在slave端加了skip-replicate-table跳过该表的相关sql,让slave能够尽快同步其他的表数据,不然n多冲值不到帐的投诉就来了。。。处理完还发现更大的问题,因为发现问题后是强行关闭数据库的,而mysql使用了myisam,再加上skip了该表的复制,所以造成了master和slave该表数据不同步,只能新建了个新库,将写库上表复制到新库中,再拷贝表到slave端,最后使用insert...select同步了数据。为什么要新建个库呢,因为mysql复制是继续sql的,所以简单的使用insert...select是无法在写和读上插入同样数据的。所以必须这么做,同样的做法还有注释掉log-bin以后拷贝文件,不过这样就要停库咯呵呵
最后么抓开发改程序,发事故报告。看来手下dba数量和质量还是要提高啊,总靠自己非要累死不可。。。。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341