欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

数据库原理 - 序列7 - Binlog与主从复制

程序员文章站 2023-02-26 13:33:06
本文节选自作者书籍《软件架构设计:大型网站技术架构与业务架构融合之道》。作者微信公众号:架构之道与术。公众号底部菜单有书友群可以加入,与作者和其他读者进行深入讨论。也可以在京东、天猫上购买纸质书籍。 6.7 Binlog与主从复制 6.7.1 Binlog与Redo Log的主要差异 在MySQL中 ......

本文节选自作者书籍《软件架构设计:大型网站技术架构与业务架构融合之道》。
作者微信公众号:架构之道与术。公众号底部菜单有书友群可以加入,与作者和其他读者进行深入讨论。也可以在京东、天猫上购买纸质书籍。

6.7 binlog与主从复制

6.7.1 binlog与redo log的主要差异

在mysql中,redo log记录事务执行的日志,binlog也记录日志,但两者有非常大的差别。首先,mysql是一个能支持多种存储引擎的数据库,innodb只是其中一种(当然,也是最主要的一种)。redo log和undo log是innodb引擎里面的工具,但binlog是mysql层面的东西。
不同于redo log和undo log用来实现事务,binlog的主要作用是做主从复制,如果是单机版的,没有主从复制,也可以不写binlog。当然,在互联网应用中,binlog有了第二个用途:一个应用进程把自己伪装成slave,监听master的binlog,然后把数据库的变更以消息的形式抛出来,业务系统可以消费消息,执行对应的业务逻辑操作,比如更新缓存。大型互联网公司都有这方面的中间件,比如阿里开源的canal,国外也有几种开源的,比如databus。
同redo log一样,binlog也存在一个刷盘策略问题,由参数sync_binlog控制,该参数有三个取值:
0:事务提交之后不主动刷盘,依靠操作系统自身的刷盘机制可能会丢失数据。
1:每提交一个事务,刷一次磁盘。
n: 每提交n个事务,刷一次磁盘。
显然,0和n都不安全。为了不丢失数据,一般都建议双1保证,即sync_binlog和innodb_flush_log_at_trx_commit的值都取为1。
知道binlog的概况后,下面对binlog 和redo log做一个详细的对比,如表6-17 所示。
表6-17 binlog与redo log的详细对比
数据库原理 - 序列7 - Binlog与主从复制
从表中可以看出,binlog要比redo log简单得多,在不发生宕机的情况下,未提交的事务、回滚的事务,其日志都不会进入binlog(对于binlog写到一半时宕机的场景,下面再讨论)。
同时,事务的日志在binlog中是连续排列的,等到事务提交的“一刹那”,把该事务的所有日志都写盘。连续排列会造成一个问题:binlog全局只有一份,每个事务都要串行地写入,这意味着每个事务在写binlog之前要拿一把全局的锁,才能保证每个事务的binlog是连续写入的,这在效率上存在很大问题。因此,在mysql 5.6的group commit出现之前,各种第三方在优化这类问题。group commit的思想也很简单,就是pipeline(http 1.1是同样的思路;kafka的主从复制也是同样的思路,后面讲高并发时,还会再专门讨论该问题)。虽然binlog只能串行地写入,但不需要提交一个事务刷一次磁盘,而是把事务的提交和刷盘放到不同的线程里,刷盘时可以对多个提交的事务同时刷盘,虽然还是串行,但是批量化了。

6.7.2 内部xa – binlog与redo log一致性问题

一个事务的提交既要写binlog,也要写redo log,如何保证两份日志数据的原子性?一个写成功,写另外一个的时候发生宕机,重启如何处理?
在讨论这个问题之前,先说一下binlog自身写入的原子性问题:binlog刷盘到一半,出现宕机。这个问题和前面讲redo log的写入原子性是同样的问题,通过类似于checksum的办法或者binlog中有结束标记,来判断出这是部分的、不完整的binlog,把最后一段截掉。对于客户端来说,此时宕机,事务肯定是没有成功提交的,所以截掉也没有问题。
下面来讲如何实现binlog和redo log的数据一致性,即内部xa,或者叫内部的分布式事务问题。外部分布式事务是两个系统或者两个数据库之间的,这点在后面的事务一致性中会专门论述;内部分布式事务是binlog和redo log之间的事务,使用的是经典的2阶段提交方案(2pc,2 phase commit)。
图6-19展示了一个事务的2阶段提交过程,下面详细分析整个提交过程。
阶段1:innodb的prepare,是在把事务提交之前,对应的redo log和undo log全部都写入了。binlog也已经写入到内存,只等刷盘。
数据库原理 - 序列7 - Binlog与主从复制
图6-19 内部xa(事务的2阶段提交过程)

阶段2:收到客户端的commit指令,先刷盘binlog,然后让innodb执行commit。
2pc的一个显著特点是,在阶段1就把90%以上的工作全部做完了,就等阶段2的收尾。所以在阶段2收到客户端的commit指令后,只要不宕机,事务就能成功提交。但如果发生宕机,如何恢复?
首先,整个过程以binlog的刷盘来判定一个事务是否被成功提交,即以binlog为准,让redo log向binlog“靠齐”。具体分为下面几种场景:
场景(1):在阶段1宕机,此时binlog全在内存中,宕机消失。redo log记录了未提交的日志。不需要依赖binlog,redo log自己可以回滚未提交的日志。这点前面已介绍过。
场景(2):阶段2宕机,binlog写了一半,innodb commit还未执行。对binlog做截断,对redo log做回滚,处理方法与场景(1)一样。
场景(3):binlog写入成功,innodb未提交。此时遍历binlog,binlog中存在、innodb中不存在的事务,发起commit操作。

6.7.3 三种主从复制方式

表6-18 列举了mysql的三种主从复制方式。对于异步复制,可能会丢数据,master宕机了,切换到slave,此时slave上没有最新的数据。所以很多时候大家用的是半同步复制。
不是半同步复制就不会丢数据呢?不是的。半同步复制可能退化为异步复制。因为master不可能无限期地等slave,当超过某个时间,slave还没有回复ack时,master就会切换为异步复制模式。
另外,还有一个参数rpl_semi_sync_master_wait_slave_count,可以设置在半同步复制模式下,需要等待几个slave的ack,才认为事务提交成功。默认是1,即多个slave中只要有其中一个返回了,master就会向客户端返回事务提交成功。
表6-18 mysql的三种主从复制方式
数据库原理 - 序列7 - Binlog与主从复制
从上面的介绍可以看出,无论异步复制,还是半异步复制(可能退化为异步复制),都可能在主从切换的时候丢数据。业务一般的做法是牺牲一致性来换取高可用性,即在master宕机后切换到slave,忍受少量的数据丢失,后续再人工修复。
但如果主从复制的延迟太大,切换到slave,丢失数据太多,也难以接受。为了降低主从复制的延迟,业界的前辈们想了很多的办法,这就是下面要讲的并行复制,在跨机房的情况下,尤其必要。

6.7.4 并行复制

图6-20展示了原生的mysql主从复制的原理,分为两个阶段:
阶段1:把master中的binlog搬运到slave上面,形成relaylog。在这个搬运过程中,master和slave两边各有一个线程,master上面的叫dump thread,slave上面的叫i/o thread。
阶段2:slave把relaylog回放到数据库,通过一个叫作sql thread的线程执行。
数据库原理 - 序列7 - Binlog与主从复制
图6-20 原生的mysql主从复制的原理
可见,整个复制过程无论log的传输过程,还是回放过程,都是单线程的。而并行复制,就是把回放环节并行化了,如图6-21所示。

图6-21 并行复制
所谓的并行复制,准确说是并行回放,因为传输环节还是单线程的。之所以传输环节没有用多线程,主要是因为没有必要。一个原因是在回放环节,而不在传输环节;另外一个原因是binlog本身是全局有序的,如果用多线程传输,还要重新排序和重组,可能得不偿失。
而并行回放的难点在于事务的并行提交。binlog本身是全局只有一份,同一个mysql的实例,不同库、不同表的事务binlog都串行地排列。所谓并行回放,就是一次性从relaylog中拿出多个事务,并行地执行。这就涉及什么样的事务能并行,什么样的事务不能并行。大的来说,有两类并发策略:
第一类:按数据维度并行。
从粗到细,三个粒度:不同库的事务可以并行,不同表的事务可以并行,不同行的事务可以并行。当然实际没有那么简单,因为一个事务可能修改多个库的多个表的多条记录,以表的粒度为例,事务1修改了记录1、2,事务2修改了记录2、3,则两个事务就无法并行了,但如果事务1修改的是记录1、2,事务2修改的是记录3、4,就可以并行。
第二类:按事务的提交顺序并行。
mysql中有commit_id的概念,表示哪些事务是同时提交的。什么意思呢?如果在一个事务还没有结束之前,另外一个事务也开始进入提交阶段,说明这两个事务是在并行的,它们操作的是肯定是不同的数据记录。所以,在回放的时候具有同样commit_id的事务可以并行。
当然,两个事务的commit_id不一样,不代表不能并行。commit_id不一样,可能仅仅是因为一个事务是在另外一个事务结束之后才开始的,它们在时间上有先后顺序,但操作的数据完全不同,用第一类并发策略仍然可以并行。
基于commit_id的并行提交策略,在mysql的版本迭代中也一直在不断优化,这涉及innodb的底层实现细节。此处只是介绍一个大概思路,如要深入研究,建议查看innodb实现源码。