MySQL主备同步延迟有多可怕？
近
期
疫
情
又有
持续爆
发的趋势，
很多企业
已开
启远程
办
公
模式，
歪哥也不例外
，
在家
憋着属实难
受，不过
在工作之余有更多时间
与家人相处也是一件
好事，
而且
有更充裕的时间
学习技能
充实自己
。
进入正题，今天讲讲MySQL的主从同步。说到主从同步，就要先看看何为主从。
高可用这个词都耳熟能详，核心思想是提高系统的容错能力。一般都会通过集群部署、主备节点来实现。备用节点就是用来当主节点挂掉时顶上去，保证系统可用。
MySQL也不例外，下面以一个最简单的主备模式为例。
可以看到，主备之间要进行数据同步，不然备库的数据从哪来呢？如果等到主备切换时候才全量同步明显是来不及的，因此这个数据同步是近实时的。
主从同步的核心是通过binlog，binlog大家都知道，就相当于一个日志记录功能，存储了MySQL操作历史，这样可以从binlog进行数据回放，主从同步也是基于此。
简单来说，备节点会copy主节点的binlog，然后再从中回放数据，一般主备节点部署在不同机器，那么主从延迟实际上主要就是两个binlog数据同步的网络时延。
延迟过高就意味着备库数据大幅落后主库，一旦发生主从切换，就意味着一段时间内，读到的是过时的数据，设想一个银行系统，突然有一天你发现你的账户少了一百万，然后客服告诉你不用惊慌，系统有延迟，等一会儿能恢复，然而你心里默念一百遍羊驼也平复不了飙到200的心率......
解决问题似乎是运维大佬的事，但与普通开发人员也是息息相关的，我们说说几点能避免或减少延迟的思路
硬件不行，再牛逼的程序也白搭，永远不变的真理，机器配置也是影响同步的主要因素之一。
一般来说，部署的时候会尽量避免这样的情况，如果备库的机器上还有像运营数据统计这类应用在跑，是会影响机器整体性能，当然资源实在紧张的话也没办法。
用惯了@Transaction注解的程序员似乎对事物变的越来越不敏感，导致业务中出现大量的冗长大事务，数据库执行完事务提交后才对外可见，备库也是同样，那么即使网络状况良好，一个十分钟的大事务也意味着表现出至少十分钟的延迟。
因此，即使是数据库部署相关的技能，也不仅仅是运维同学需要掌握的，知其所以然，才能在平时开发过程中避免挖坑。
标签:
