阅读 722

MySQL 入门(5):复制

摘要

在这篇文章中,我将从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 网络问题

网络确实可能会造成主从延迟,比如主库或者从库的带宽打满,又或者是主库的bin log被设置成了row格式,导致有大量的数据需要传输,造成了主库的bin log没有及时的同步到从库中,导致了主从的延迟。

4.2 机器性能

但是除了网络,更多的是从库的消费速度,跟不上主库的生产速度。

这方面有很多原因,比如可能从库的机器配置低于主库,因为会有人觉得既然是备库,没什么请求,就把备库配置在了比较差的机器上面。

又或者在是后台的数据分析,将CPU打满。

总之,如果在从库中需要有大量的查询分析操作,需要考虑多个从库。

4.3 大事务

如果主库执行了一条耗时很长的事务,那么这条事务发送到从库中,可能也需要执行这么长的时间。而这个时候,从库是没有办法继续消费新的relay log的。这就造成了主从延迟。

4.4 锁

我们之前提到过了,不仅仅写数据会加锁,使用“当前读”,也一样可能会加锁。

所以,如果在从库上执行了一些诸如select ... for update,或者一些DDL语句,可能也会造成从库加锁,导致主从延迟。

4.5 并发

在我们上面的介绍中,SQL线程是单线程的,所以,如果能够让SQL线程可以并发消费,那么主从延迟就可以大幅度的降低了。

关于MySQL的并发复制策略,MySQL5.6开始已经正式支持了,本文不详细解释。

写在最后

首先,谢谢你能看到这里。

这一篇的文章,其实说的内容不多,大多都是一些理论性质的内容,目的是能够对MySQL的主从复制有一些大体上的了解,并且知道对于延迟方面的问题,应该从哪个方向去考虑。

至于其他更具体的操作、如何调优,以及更深的原理,我想在今后的《进阶篇》来提到。

并且,《MySQL 入门》系列到这里就完结了。希望这五篇的内容能够给你带来一些帮助,能够让你对MySQL的了解更深一些。

当然了,在学习MySQL的过程中,我可能也会有一些错误的理解,如果有哪里是不对的,希望你能指出,谢谢你!

PS:如果有其他的问题,也可以在公众号找到我,欢迎来找我玩~

文章分类
后端
文章标签