vlambda博客
学习文章列表

阿里二面挂在了如何解决MySQL同步延迟,回来后连夜总结排雷

MySQL应用里,最让人放心不下的就是同步延迟的问题,这个问题的原因由多方面构成,但其带来影响确是非常大,甚至都没办法解释。MySQL绝对是当今最流行的数据库之一,虽然在速度和复制能力上不是特别的强,但你如果要对其依赖那么必须处理同步延迟的问题,今天就说一下如何尽量避免此类事情的发生。


1.应用解决方案

我们假设延迟于开发种存在,就必须严谨对待核心业务,举个例子,比如说文章队列,假设无法获取从库文章信息,是选择再次对队列进行投递还是从主库进行查询来尽量减少延迟造成的影响,这样就会增加设计的复杂程度。如果你选择依赖缓存,那就会面临一个更难处理的问题,如何筛选干净的缓存信息。


2.减负

MySQL要要保持数据量可控的。分享一个我用过的好办法,在不影响应用的前提下删除数据,虽然这个方法一点都不高端,但是管用呀。

尽量减少慢查询,之前同步延迟都是查询造成的,但也有例外,队列的大量更新和插入也会造成同步延迟,比如每天全量推送用户,长时间高并发写就会造成同步延迟,所以对并发写入和更新数量要有一定的控制。

3.选择合适的解决方案

MySQL最好是作为储存来使用,它的优势并不在于大规模的查询和更新,所以采用redis和mongodb处理非核心业务是比较好的。如果是队列的解决方案,就更不建议使用MySQL,或者说选用多套解决方案。


4.拆分

因为MySQL本身的机制有限,我们可以通过升级版本来提升并行复制能力。根据不同的场景,使用多个库,甚至多个MySQL实例来避免核心的服务受到影响。服务不仅可以解耦,对于拓展也非常的方便,分而治之就是这个意思。

5.负载均衡

有时候会有一台从库延迟,其余不延迟的情况出现,我们可以通过策略来摘除这个从库,但这仅仅是一个临时的方案,无法做到一劳永逸,如果出现了大量的延迟,则说明问题已经比较严重了。

写在文章末尾

最后来说一下判断主从延迟的方法。

MySQL提供了从服务器状态命令,这个是可以通过 show slave status 来查看,比如可以通过Seconds_Behind_Master参数的值来判断,是否有发生主从延时。其值有这么几种:
NULL - 表示io_thread或是sql_thread有任何一个发生故障,也就是该线程的Running状态是No,而非Yes.
0 - 该值为零,是我们极为渴望看到的情况,表示主从复制状态正常