23 | MySQL是怎么保证数据不丢的？

最新推荐文章于 2022-09-26 18:45:42 发布

sxlxwyr

最新推荐文章于 2022-09-26 18:45:42 发布

阅读量237

点赞数

分类专栏： MySQL

原文链接：https://time.geekbang.org/column/article/76161

版权

48 篇文章 3 订阅

订阅专栏

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

binlog的写入机制

binlog的写入逻辑比较简单：事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。

系统给binlog cache分配了一片内存，每个线程一个，参数binlog_cache_size用于控制单个线程binlog cache所占内存的大小。如果超过了这个参数规定的大小，就要暂存磁盘。

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

每个线程都有自己的binlog cache，但是共用一份binlog文件。

write和fsync的时机，由参数sync_binlog控制：

实际场景中，比较常见的是是将其设置成100~1000中的某个数值。这样对应的风险是：如果主机发生异常重启，会丢失对应数值的binlog日志。

事务执行过程汇总，生成的redo log先写到redo log buffer中。

每次生成后不需要直接持久化到磁盘。

事务还没提交的时候，有可能redo log buffer中的部分日志也有可能被持久化到磁盘。

redo log可能存在的三种状态：

三种状态分别是：

写到redo log很快，write到page cache也差不多，持久化到磁盘的速度就慢多了。

为了控制redo log的写入策略，InnoDB提供了innodb_flush_log_at_trx_commit参数，有三种可能取值：

InnoDB有一个后台线程，每隔1秒，会把redo logbuffer中的日志，调用write写到系统的page cache，然后条用fsync持久化到磁盘。

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

除了后台线程，还有两种场景也会让一个没有提交的事务的redo log写入到磁盘中：

redo log占用的空间即将达到innodb_log_buffer_size一般的时候，后台线程会主动写盘。注意，由于事务没有提交，这个写盘动作只是write，没有调用fsync，就是只留在了文件系统的page cache。
并行的事务提交的时候，顺带将这个事务的redo logbuffer持久化到磁盘。

MySQL的“双1”配置，指的是sync_binlog和innodb_flush_log_at_trx_commit都设置成1，意思是，一个事务完整提交前，需要等待两次刷盘，一次是redo log（prepare阶段），一次是binlog。

组提交机制

如果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。

关注