「这是我参与2022首次更文挑战的第24天，活动详情查看：2022首次更文挑战」
前言
Mysql主备同步的流程是什么？是怎么解决循环复制问题的？主备延迟的原因有哪些？怎么解决主备延迟呢？
下面我们来了解下。
主备流程
如上图A为主库，B为从库，描述了主库到从库同步一个事务的流程-从binlog在主库上生成到从库拿到并解析执行日志的命令完成和主库一样的事务操作：
备库B跟主库A之间维持了一个长连接。主库A内部有一个线程，专门用于服务备库B的这个长连接。
- 在备库B上通过change master命令，设置主库A的IP、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含了文件名和日志偏移量。
- 在备库B上执行start slave命令，这个时候备库会启动两个线程，就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接。
- 主库A校验完用户名、密码后，开始按照备库B传过来的位置，从本地读取binlog，发给B。
- 备库B拿到binlog后，写本地文件，称为中转日志（relay log）。
- sql_thread读取中转日志，解析出日志里的命令，并执行。
循环复制问题
上图为主备切换流畅-双M结构。为啥需要主备切换呢？当线上数据库出现问题时，我们可以先把备库切换成主库，主库切换成备库，这也就能不影响线上使用。
log_replica_updates是默认打开的，表示备库上执行主库传过来的binlog也会生成binlog。这是合理的因为备库上修改数据库需要完整的记录在binlog中，同时如果出现多个备库，可以建立-主同步主备，然后再通过主备同步其他多个副备，能减少主库的性能开销，具体见官方文档。
所以如果是主备切换的话就会出现出现循环复制问题，这个mysql已经考虑到了，就是之前文章《Mysql之查看和使用Binary Log》有展示binary log的日志中不管是row格式还是satatment格式都会存在server id，通过它mysql在执行的时候会判断是不是自己产生的binlog，所以不会出现循环复制。（当然备库执行主库产生的binary log的server id还是主库的）
注意:
要修改
server_id，默认的为1。
主备延迟
主备延迟的表现在于备库落后主库，或者主库落后备库。
备库落后主库来源
备库落后主库的原因在于binary log在主库上产生之后需要传输到备库，备库先记在relay log中，备库拿取并解析relay log并执行，从传输到执行肯定会有时间差，可以通过show slave status命令执行输出的seconds_bind_master（通过当前执行事务的时间减去同步过来的binary log中记录的执行时间计算）查看当前备库延迟了多少秒。
网络延迟
传输过程中，网络不好，导致的。
机器性能差
备库的机器性能不如主库好，跟不上主库的节奏。
备库压力大
备库执行大的查询，把机器的性能榨干了。可能IO繁忙传输过来的binary log无法及时保存在relay log中。可能已经保存在relay log中没法立即执行。
大事务
主库传过来的事务需要执行长时间，变现出来就是同步延迟了。
大表DDL
和前面的大事务类似，主库执行大表DDL需要长时间，备库也是。
并行复制能力
备库复制参数配置跟不上业务的增长。
主库落后备库来源
有些人会想主库咋回落后备库呢？会出现的，当一主多备的时候，为了保证备库和主库的一致性，提供了完全同步复制，主库的事务需要等到所有备库都ack之后才提交，如果有一个备库ack比较慢，其中一个备库ack比较快都已经执行复制了，那么就会出现主库落后备库，当然一般不使用全同步复制，可以使用半同步复制或者不保证一致性直接使用默认的异步。
解决主备延迟
上面主库落后备库其实是配置的问题，解决方案已经提到了。下面我们主要讲这么解决备库落后主库。如下图：
这个操作方案的缺点在于，主动等会影响业务正常进行不能进行写数据。
可靠性优先策略
设置一个阈值如果大于等于这个值就把主库设置成readonly，直到备库赶上了落后秒数小于阈值。
可用性优先策略
为了解决“可靠性优先策略”的弊端可以进行主备切换，让备库可读写，这样业务能正常的写了，但是部分数据读存在延迟。
最终策略
笔者认为可以先从“备库落后主库来源”根据进行分析，比如网络延迟——尽量在一个组网内等等，机器性能差——备库服务器和主库使用一样性能的机器等等，备库压力大-搞多个备库等等，大事务-设计不合理减少大事务等等，大表DDL——在业务不繁忙的进行等等，并行复制能力-关注业务增长修改参数等等，如果实在不行就使用可靠策略，在凌晨完成同步等等。
