背景

前段时间遇到一个线上问题，起初排查良久发现是因为主从同步提早导致的，所以明天写一篇文章总结一下这个问题心愿对你有用。如果感觉还不错, 记得加个关注点个赞哦

思维导图

常见的主从架构

随着日益增长的访问量，单台数据库的能力曾经顾此失彼。因而采纳主库写数据，从库读数据这种将读写分来到的主从架构便随之衍生了进去。

一主一从

一主多从

一主一从和一主多从是最常见的主从架构，施行起来简略并且无效，不仅能够实现高可用，还能读写拆散，进而晋升集群的并发能力。

多主一从

双主复制

级联复制

主从同步原理

想要理解主从同步原理，首先得记住两个很重要的日志文件

• binlog（二进制日志文件）
• relay log（中继日志文件）

主从同步过程

• 从库生成两个线程，一个 I / O 线程，一个 SQL 线程；
• i/ o 线程去申请主库 的 binlog，并将失去的 binlog 日志写到 relay log（中继日志）文件中；
• 主库会生成一个 log dump 线程，用来给从库 i/ o 线程传 binlog

• SQL 线程，会读取 relay log 文件中的日志，并解析成具体操作，来实现主从的操作统一，而最终数据统一；

  如何判断主从是否延时

  通过监控 show slave status 命令输入的 Seconds_Behind_Master 参数的值来判断：

• NULL，示意 io_thread 或是 sql_thread 有任何一个产生故障；
• 0，该值为零，示意主从复制良好；
• 正值，示意主从曾经呈现延时，数字越大示意从库提早越重大。

主从提早起因

随机重放

MySQL 的主从复制都是单线程的操作，主库对所有 DDL 和 DML 产生的日志写进 binlog，因为 binlog 是程序写，所以效率很高。Slave 的 SQL Thread 线程将主库的 DDL 和 DML 操作事件在 slave 中重放。DML 和 DDL 的 IO 操作是随机的，不是程序的，老本高很多。所以 SQL Thread 线程的速度赶不上主库学 binlog 的速度，就会产生主从提早

锁期待

另一方面，因为 SQL Thread 也是单线程的，当主库的并发较高时，产生的 DML 数量超过 slave 的 SQL Thread 所能解决的速度，或者当 slave 中有大型 query 语句产生了锁期待那么延时就产生了。

主从提早解决办法

并行复制

既然 SQL 单线程进行重放时速度无限，那么能不能采纳多线程的形式来进行重放呢？MySQL 5.6 版本后，提供了一种并行复制的形式，通过将 SQL 线程转换为多个 work 线程来进行重放，这样就解决了主从提早的问题

升高并发

如果你了解了随机重放这个导致主从提早的起因，那么就比拟好了解了，管制主库写入的速度，主从提早产生的概率天然就小了。

读主库

如果你做的是相似领取这种对实时性要求十分高的业务，那么最间接的办法就是间接读主库。

几句唠叨

大家好，我是小饭，一枚后端工程师。如果感觉文章对你有一点点帮忙，欢送分享给你的敌人，也给小饭点个赞，上面是我的公众号，感兴趣能够关注，这是小饭坚持下去的能源，谢谢大家，咱们下次见！