在这篇文章中，我将从MySQL为什么需要主从复制开始讲起，然后会提到MySQL复制的前提，bin log。
在这里会说明三种格式的bin log分别会有什么优缺点。
随后会讲到主从延迟方面的问题，我将从几个角度出发，提供一些可能造成延迟的思路。
1 为什么需要复制MySQL内建的复制功能是构建大型，高性能应用程序的基础。随着目前并发量的增加，单机的MySQL渐渐没有办法承担这些请求，所以MySQL服务器也需要进行扩展。
MySQL的复制功能不仅可以提高可用性，还能用作灾备，数据仓库等。
2 如何复制说到复制，那么问题的关键就在于数据从主库复制到从库时间需要多少，准确度能有多高。
对于MySQL来说，复制使用的是bin log。
对于bin log相信你不会陌生，我们在聊到MySQL的“两阶段提交”的时候有说到这个。
也就是说，MySQL会将主库记录的bin log发送到从库中，然后从库按照bin log的内容，“重放一遍”主库执行过的操作，达到主从同步的目的。
在这里我们先详细说一说bin log记录了什么。
2.1 SBR（statement-based replication）在这种模式下，bin log会完整的记录下所执行的SQL语句。也就是说，如果使用了statement格式的bin log的话，主库执行的SQL语句就会在从库中完整的再执行一遍。
可是，这样的做法，是有可能导致主从不一致的。
例如下面这样的语句：
delete from t where a >= 1 and b => 2 limit 1;这样的语句在从库中就不一定能够实现跟主库一样的效果。因为我们不能够确定在从库中是否走的跟主库是同样的索引，所查找的第一条数据，是不是跟主库一样的，也就可能删除的数据不是同一行。
又或者主库执行的SQL语句里面有一些锁相关的语句，也可能会造成主从不一致的问题。
但是要注意的是，NOW()函数是可以被正确执行的，因为在bin log语句中会记录时间戳。
也就是说，基于statement模式，在上下文不同的时候，是有可能造成数据不一致的。
至于其他的不安全情况，可以参考官方文档，这里不展开介绍。
2.2 RBR（row-based replication）既然statement模式下会造成数据不一致，那么有没有一种模式是上下文无关的呢？
所以就有了row模式。
在这个模式中，bin log中只记录了所操作的行的修改情况，会精确到某一行。
比如你更新了某一行，在bin log中就会记录在id等于多少多少，某某字段等于多少多少的行中，将某个字段的值从A改成了B。
甚至是删除操作，都会记录删除了id等于多少，A字段等于多少，B字段等于多少的一行数据。
听到这里你可能会觉得很方便，也很精确，主从不再会发生不一致的情况了。甚至于删库了都不需要跑路了，只需要查看bin log就能恢复相应的数据了。
但是使用row模式同样会有一些问题。比如你在主库执行了delete from t where id < 10000这么一行sql语句，如果使用statement格式，在bin log内记录只有这么一条，但是如果你使用的是row模式，那么就需要记录10000条数据，占用很大的空间。
2.3 MBR（mixd-based replication）于是就有了mixd模式。
混合了以上两种模式的优点，MySQL会在没有歧义的时候使用statement格式，在有歧义的时候使用row格式。
3 复制的具体过程上面介绍了bin log的作用，以及bin log的组成形式，在这一章中我们聊一聊整个的复制流程。
我们拿《高性能MySQL》中的图来解释：
这里涉及到了有三个线程：
Binlog dump thread
这个线程在MySQL主库中，负责读取bin log中的内容，并将这些内容推送到从库IO进程中。
I/O thread
这个线程在MySQL从库中，负责跟主库建立一条长连接，并且将读取到的bin log数据保存到从库的中继日志（relay log）中。
SQL thread
这个线程也是在MySQL的从库中，负责读取中继日志中的内容，然后执行这些语句，将对数据的修改应用到从库中。
简单的来讲，就是主库经过两阶段提交后，把修改内容保存在了bin log中，然后把这个bin log发送给从库，让从库也执行一次，以达到同步的目的。
而这里采用了中继日志的原因是从库消费bin log的速度和主库生产bin log的速度是不一致的，所以需要一个中继日志作为缓冲。
4 复制可能造成的问题在MySQL复制的过程中，经常出现的问题是延迟。
假设我们把主库一个事务提交后bin log落盘的时间点设为t1
把从库接受到主库新事务写的bin log并写入relay log的时间节点设为t2
把从库执行完这个新的事务的时间节点设为t3
那么执行一条事务，从库的延迟可以认为是（t3 - t1）。
也就是说，如果我们需要分析造成主从延迟的原因，应该从两个方面考虑：传输过程，以及从库消费relay log的速度。
4.1 网络问题