手下做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数量和质量还是要提高啊，总靠自己非要累死不可。。。。
