写点什么

MySQL 是怎么保证 redo log 和 binlog 是完整的?

  • 2022 年 2 月 25 日
  • 本文字数:3730 字

    阅读完需:约 12 分钟

本文分享自华为云社区《MySQL会丢数据吗?》,作者: JavaEdge 。

在业务高峰期临时提升性能的方法。

WAL 机制保证只要 redo log 和 binlog 保证持久化到磁盘,就能确保 MySQL 异常重启后,数据可以恢复。

binlog 的写入机制

事务执行过程中:

  • 先把日志写到 binlog cache

  • 事务提交时,再把 binlog cache 写到 binlog 文件

一个事务的 binlog 不该被拆开,不论事务多大,也要确保一次性写入。这就涉及 binlog cache 的保存问题。

系统给 binlog cache 分配了一片内存,每个线程一个,但是共用同一份 binlog 文件。参数 binlog_cache_size 控制单个线程内 binlog cache 所占内存的大小。若超过该参数值,就要暂存到磁盘。

事务提交时,执行器把 binlog cache 里的完整事务写入 binlog,并清空 binlog cache。

  • binlog 写盘状态

TODO

  • write

把日志写入到文件系统的 page cache,并没有把数据持久化到磁盘,所以速度较快

  • fsync

将数据持久化到磁盘。一般认为 fsync 才占磁盘的 IOPS

write 和 fsync 的时机,由参数 sync_binlog 控制:

  • sync_binlog=0,每次提交事务都只 write,不 fsync

  • sync_binlog=1,每次提交事务都会执行 fsync

  • sync_binlog=N(N>1),每次提交事务都 write,但累积 N 个事务后才 fsync


因此,在出现 I/O 瓶颈的场景,将 sync_binlog 设置成一个较大值,可提升性能。在实际的业务场景中,考虑到丢失日志量的可控性,一般不建议将这个参数设成 0,推荐将其设置为 100~1000 中的某个数值。

但将 sync_binlog 设置为 N,对应的风险是:若主机发生异常重启,会丢失最近 N 个事务的 binlog 日志。

redo log 的写入机制

接下来,我们再说说 redo log 的写入机制。

事务在执行过程中,生成的 redo log 是要先写到 redo log buffer 的。

  • 那 redo log buffer 的内容,是不是每次生成后都要直接持久化到磁盘呢?

不需要。


若事务执行期间 MySQL 异常重启,那这部分日志就丢了。由于事务也尚未提交,所以这时日志丢了也没有损失。

  • 那事务还没提交时,redo log buffer 中的部分日志有没有可能被持久化到磁盘呢?

会有。

这个问题,要从 redo log 可能存在的三种状态说起。这三种状态,对应的就是图 2 中的三个颜色块。

  • MySQL redo log 存储状态

TODO

三种状态:

  • 存在 redo log buffer

物理上是在 MySQL 进程内存

  • 写到磁盘(write),但还没持久化(fsync)

物理上是在文件系统的 page cache

  • 持久化到磁盘,即 hard disk


日志写到 redo log buffer 很快,wirte 到 page cache 也差不多,但持久化到磁盘就很慢了。


InnoDB 提供 innodb_flush_log_at_trx_commit 参数控制 redo log 的写入策略:

  • 0,每次事务提交时都只是把 redo log 留在 redo log buffer 中

  • 1,每次事务提交时都将 redo log 直接持久化到磁盘

  • 2,每次事务提交时都只是把 redo log 写到 page cache


InnoDB 的一个后台线程,会每隔 1s 把 redo log buffer 中的日志,调用 write 写到文件系统的 page cache,然后调用 fsync 持久化到磁盘。


事务执行中间过程的 redo log 也是直接写在 redo log buffer,这些 redo log 也会被后台线程一起持久化到磁盘。即一个没有提交的事务的 redo log,也可能已经持久化到磁盘。


除了后台线程每 s 一次的轮询操作,还有两种场景会让一个未提交的事务的 redo log 写入磁盘:

  • redo log buffer 占用的空间即将达到 innodb_log_buffer_size 的一半,后台线程会主动写盘

由于这个事务并未提交,所以这个写盘动作只是 write,没有调用 fsync,即只留在文件系统的 page cache。

  • 并行的事务提交时,顺带将该事务的 redo log buffer 持久化到磁盘

假设一个事务 A 执行到一半,已经写了一些 redo log 到 buffer,这时另外一个线程的事务 B 提交,若 innodb_flush_log_at_trx_commit 是 1,则事务 B 要把 redo log buffer 里的日志全部持久化到磁盘。这时,就会带上事务 A 在 redo log buffer 里的日志一起持久化到磁盘。


两阶段提交的过程,时序上 redo log 先 prepare,再写 binlog,最后再把 redo log commit。


若把 innodb_flush_log_at_trx_commit 置 1,则 redo log 在 prepare 阶段就要持久化一次,因为有一个崩溃恢复逻辑是要依赖于 prepare 的 redo log,再加上 binlog 来恢复的。


每 s 一次的后台轮询刷盘,再加上崩溃恢复,InnoDB 就认为 redo log 在 commit 时无需 fsync,只 write 到文件系统的 page cache 就够了。


通常我们说 MySQL 的“双 1”配置,指的就是 sync_binloginnodb_flush_log_at_trx_commit 都是 1。即一个事务完整提交前,需要等待两次刷盘:

  • redo log(prepare 阶段)

  • binlog


那这意味着我从 MySQL 看到 TPS 是 2w,每秒就会写四万次磁盘。但我用工具测试,磁盘能力也就 2w 左右,怎么能实现 2w TPS?


得用组提交(group commit)来解释了。

日志逻辑序列号(log sequence number,LSN)

LSN 单调递增,对应 redo log 的写入点。比如写入 length 长度的 redo log, 则 LSN+length。

LSN 也会写到 InnoDB 的数据,以确保数据页不会被多次执行重复的 redo log。


如图 3 所示,是三个并发事务(trx1, trx2, trx3)在 prepare 阶段,都写完 redo log buffer,持久化到磁盘的过程,对应的 LSN 分别是 50、120 和 160。


  • redo log 组提交

TODO

  • trx1 第一个到达,被选为这组的 leader

  • 等 trx1 要开始写盘,组里已经有了三个事务,LSN 也变成了 160

  • trx1 去写盘时,带的就是 LSN=160。所以,等 trx1 返回时,所有 LSN≤160 的 redo log,都已被持久化到磁盘

  • 这时,trx2 和 trx3 就可直接返回


所以,一次组提交里,组员越多,节约磁盘 IOPS 效果越好。但若只有单线程压测,则只能老老实实地一个事务对应一次持久化操作。


在并发更新场景下,第一个事务写完 redo log buffer 后,接下来这个 fsync 越晚调用,组员可能越多,节约 IOPS 效果越好。


为了让一次 fsync 带的组员更多,MySQL 采取优化:拖时间。


  • 两阶段提交

写 binlog 实际上分成两步:

  1. 先把 binlog 从 binlog cache 中写到磁盘上的 binlog 文件

  2. 调用 fsync 持久化


MySQL 为了让组提交效果更好,把 redo log 做 fsync 的时间拖到了 step1 后面:


  • 两阶段提交细化

这样的话,binlog 也可以组提交。上图的 step4 时,若有多个事务的 binlog 已经写完,也是一起持久化的,这样也能减少 IOPS。一般 step3 执行很快,所以 binlog 的 write、fsync 间隔时间很短,导致能集合到一起持久化的 binlog 较少,因此 binlog 的组提交的效果通常不如 redo log 的效果。


若想提升 binlog 组提交效果,可设置:

  • binlog_group_commit_sync_delay 参数

延迟多少微秒后才调用 fsync

  • binlog_group_commit_sync_no_delay_count 参数

累积多少次以后才调用 fsync


这两个条件是或的关系,即只要有一个满足条件就会调用 fsync。


这样的话,binlog_group_commit_sync_delay = 0 时,binlog_group_commit_sync_no_delay_count 就无效了。


WAL 是减少磁盘写,可每次提交事务都要写 redo log 和 binlog,这磁盘的读写次数也没变少呀?s 所以现在就能理解了,WAL 主要得益于:

  • redo log 和 binlog 都是顺序写,磁盘的顺序写比随机写速度要快

  • 组提交机制,可大幅度降低磁盘 IOPS

所以,若 MySQL 出现 IO 性能瓶颈,可通过如下方法优化:

  • 设置 binlog_group_commit_sync_delay 、binlog_group_commit_sync_no_delay_count,减少 binlog 写盘次数

该方案是基于“额外的故意等待”来实现的,因此可能会增加语句的响应时间,但不会丢数据

  • sync_binlog 设为大于 1 的值(推荐 100~1000)

风险是,主机掉电时会丢 binlog 日志。

  • innodb_flush_log_at_trx_commit 设为 2

风险是,主机掉电的时候会丢数据。


不推荐把 innodb_flush_log_at_trx_commit 设成 0。因为此时表示 redo log 只保存在内存,这样 MySQL 本身异常重启也会丢数据,风险太大。而 redo log 写到文件系统的 page cache 的速度是很快的,所以将该参数设成 2 跟设成 0 性能差不多,但这样做 MySQL 异常重启时就不会丢数据了。

小结

MySQL 是“怎么保证 redo log 和 binlog 是完整的”。


crash-safe

  • 执行一个 update 后,再执行 hexdump 直接查看 ibd 文件内容,为什么没有看到数据有改变?

可能因为 WAL。update 语句执行完后,InnoDB 只保证写完了 redo log、内存,可能还没来得及将数据写磁盘。

  • 为什么 binlog cache 是每个线程自己维护的,而 redo log buffer 是全局共用?

binlog 不能“被打断”。一个事务的 binlog 必须连续写,因此要整个事务完成后,再一起写到文件。

  • 而 redo log 没有这个要求,中间有生成的日志可以写到 redo log buffer。redo log buffer 中的内容还能“搭便车”,其他事务提交的时候可以被一起写到磁盘。

  • 事务执行期间,还没到提交阶段,若发生 crash,redo log 肯定丢了,这会不会导致主备不一致呢?

不会。因为此时 binlog 还在 binlog cache,没发给备库。crash 之后,redo log 和 binlog 都没有了,从业务角度看这个事务也没有提交,所以数据是一致的。

若 binlog 写完盘以后发生 crash,这时还没给客户端答复就重启了。等客户端再重连进来,发现事务已经提交成功了,这是不是 bug?

不是。设想一下更极端场景,整个事务都提交成功,redo log commit 完成了,备库也收到 binlog 并执行了。但主库和客户端网络断了,导致事务成功的包返回不回去,这时客户端也会收到“网络断开”的异常。这种也只能算是事务成功的,不能认为是 bug。


实际上 DB 的 crash-safe 保证的是:

  • 如果客户端收到事务成功的消息,事务就一定持久化了

  • 如果客户端收到事务失败(比如主键冲突、回滚等)的消息,事务就一定失败了

  • 如果客户端收到“执行异常”的消息,应用需要重连后通过查询当前状态来继续后续的逻辑。此时 DB 只需要保证内部(数据和日志之间,主库和备库之间)一致即可。


点击关注,第一时间了解华为云新鲜技术~


发布于: 刚刚阅读数: 2
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
MySQL是怎么保证redo log和binlog是完整的?