十六、mysql中如何保证数据的可靠性

最新推荐文章于 2024-03-04 14:09:04 发布

发哥1997

最新推荐文章于 2024-03-04 14:09:04 发布

阅读量1.4k

点赞数

分类专栏： mysql 文章标签： mysql 数据可靠性

本文链接：https://blog.csdn.net/yabushandaxue/article/details/104136593

版权

mysql 专栏收录该内容

24 篇文章 1 订阅

订阅专栏

MySQL写入binlog 和redo log 的流程

binlog 的写入机制

redo log 的写入机制

如果MySQL出现了性能瓶颈，而且瓶颈在IO上，可以通过哪些方法来提升性能？

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

MySQL写入binlog 和redo log 的流程

binlog 的写入机制

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

一个事物的binlog 是不能被拆开的，因此不论这个事物多大，也要确保一次性写入，这就涉及到了binlog cache的保存问题。

系统给binlog cache 分配了一片内存，每个线程一个，参数binlog_cache_size用于控制单个线程内binlog cache所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。事物提交的时候，执行器把binlog cache里的完整事物写入到binlog 中，并清空binlog cache。

binlog写盘状态

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

途中的write，指的就是把日志写入到文件系统的page cache，并没有把数据持久化到磁盘，所以速度比较快；

图中的fsync，才是将数据持久化到磁盘的操作，一般情况下，fsync才占磁盘的IOPS。

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

1、sync_binlog=0,表示每次提交事务都只write，不fsync；

2、sync_binlog=1,表示每次提交事务都会执行fsync；

3、sync_binlog=N(N>1)，表示每次提交事务都write，但累积N个事物后才fsync。

因此，在出现IO瓶颈的场景里，将sync_binlog设置成一个比较大的值，可以提升性能。在实际的业务场景中，考虑到丢失日志量的可控性，一般不建议将这个参数设成0，比较常见的是将其设置为100~1000中的某个数值。

但是，将sync_binlog设置为N，对应的风险是：如果主机发生异常重启，会丢失最近N个事物的binlog日志。

redo log 的写入机制

事物在执行过程中，生成的redo log是要先写到redo log buffer的。redo log buffer里面的内容并非每次生成后都要直接持久化到磁盘的。

如果事物执行期间MySQL发生异常重启，那这部分日志就丢了。由于事物并没有提交，所以这时日志丢了也不会有损失。

事物还没提交的时候，redo log buffer中的部分日志也有可能被持久化到磁盘。这个问题需要从redo log 可能存在的三种状态说起：

1、存在redo log buffer中，物理上是在MySQL进程内存中；

2、写到磁盘（write），但是没有持久化(fsync)，物理上是在文件系统的page cache 里面；

3、持久化到磁盘，对应的是hard disk。

日志写到redo log buffer是很快的，write到page cache也差不多，但是持久化到磁盘的速度就慢多了。为了控制redo log 的写入策略，InnoDB提供了innodb_flush_log_at_trx_commit参数，它有三种可能取值：

1、设置为0的时候，表示每次事物提交时都只是把redo log 留在redo log buffer 中；

2、设置为1的时候，表示每次事物提交时都将redo log直接持久化到磁盘；

3、设置为2 的时候，表示每次事物提交时都只是把redo log写到page cache。

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

注意：事物执行中间过程的redo log 也是直接写在redo log buffer 中的，这些redo log也会被后台线程一起持久化到磁盘。也就是说，一个没有提交的食物的redo log，也是可能已经持久化到磁盘的。实际上，除了后台线程每秒一次的轮询操作外，还有两种场景会让一个没有提交的食物的redo log 写入到磁盘中：

1、redo log buffer占用的空间即将达到innodb_log_buffer_size一半的时候，后台线程会主动写入到磁盘中。由于这个事物并没有提交，所以这个写盘动作只是write，而没有调用fsync，也就是只留在了文件系统的page cache。

2、并行的事物提交的时候，顺带将这个事物的redo log buffer持久化到磁盘。

两阶段提交，时序上redo log先prepare，再写binlog，最后再把redo log commit.