云游戏网站在线玩,佛山做网站的公司哪家好,高档vi设计公司,国外免费搭建网站源码文章目录 前言Buffer Pool 和 DML 的关系DML操作流程加载数据页更新记录 数据持久化方案合适的时机刷盘双写机制日志先行机制日志刷盘机制Redo Log 恢复数据 总结 前言
上篇文章《InnoDB在SQL查询中的关键功能和优化策略》对InnoDB的查询操作和优化事项进行了说明。但是#… 文章目录 前言Buffer Pool 和 DML 的关系DML操作流程加载数据页更新记录 数据持久化方案合适的时机刷盘双写机制日志先行机制日志刷盘机制Redo Log 恢复数据 总结 前言
上篇文章《InnoDB在SQL查询中的关键功能和优化策略》对InnoDB的查询操作和优化事项进行了说明。但是MySQL作为一个存储数据的产品怎么确保数据的持久性和不丢失才是最重要的感兴趣的可以跟随本文一探究竟。
Buffer Pool 和 DML 的关系
InnoDB中的「Buffer Pool」除了在查询时起到提高效率作用同样在insert、update、delete这些DML操作时为了减少和磁盘的频繁交互也会将这些更新先在Buffer Pool中缓存的数据页进行操作随后将这些有更新的「脏页」刷到磁盘中。
这个时候就涉及到一个问题如果MySQL服务宕机了这些在内存中更新的数据会不会丢失
答案是一定会存在丢失现象的只不过MySQL做到了尽量不让数据丢失。接下来来看一下MySQL是怎么做的。
这里还是把结构图贴一下方便下面介绍时看图理解。 DML操作流程
加载数据页
通过上文可以知道行记录是在数据页中所以当InnoDB接收到DML操作请求后还是会去找「数据页」查找的过程跟上文查询行记录流程是一样。这里说一下insert的请求会根据主键索引去找数据页update、delete根据查询条件去找数据页总之「数据页」要加载到「Buffer Pool」之后才会进行下一步操作。
更新记录
定位到数据页后insert操作就是往数据页中添加一行记录delete是标记一下行记录的‘删除标记’而update则是先删除再添加这是因为存在可变长的字段类型比如varchar每次更新时这种类型的数据占用内存是不固定的所以先删除再添加。
这里的删除标记是行记录的字段也就是除了业务字段数据InnoDB默认为每行记录添加的字段所以一个行记录大概如下图这也是之前提到过的「行格式」。 找到数据页并且更新记录之后DML操作就算完成了但是还没有落地到磁盘。 这个时候直接刷新到磁盘视为完成不可以吗 数据持久化方案
可以是可以但是如果每次的DML操作都要将一个16KB的数据页刷到磁盘其效率是极低的估计也就没有人用MySQL了。但是如果不刷新到磁盘就会发生MySQL服务宕机数据会丢失现象。MySQL在这里的处理方案是
等待合适的时机将批量的「脏页」异步刷新到磁盘。先快速将更新的记录以日志的形式刷新到磁盘。
先看第一点什么时候是合适的时机
合适的时机刷盘
当「脏页」在「Buffer Pool」中达到某个阈值的时候InnoDB会将这些脏页刷新到磁盘中。这个阈值可以通过 innodb_max_dirty_pages_pct 这个参数查看或设置相关命令如下
-- 查看脏页刷新阈值
show variables like innodb_max_dirty_pages_pct
-- 在线设置脏页刷新阈值当脏页在Buffer Pool占用70%的时候刷新
SET GLOBAL innodb_max_dirty_pages_pct 70当然这个合适的时机只是为了减少与磁盘的交互用来提高性能的并不能确保数据不丢失。
双写机制
在刷新「脏页」这里还有一个非常重要的注意事项就是因为InnoDB的页大小为16KB而一般操作系统的页大小为4KB。意味着InnoDB将这些「脏页」向磁盘刷新时在操作系统层面会被分成4个4KB的页这样的话如果其中有一页因为MySQL宕机或者其他异常导致没有成功刷新到磁盘就会出现「页损坏现象」数据也就不完整了。 所以InnoDB在这里采用的双写机制在将这些「脏页」刷新到磁盘之前先会往结构图中的「Doublewrite Buffer」中写入随后再刷新到对应的表空间中当出现故障时就可以通过双写缓冲区进行恢复。 向「Doublewrite Buffer」就不会发生「页损坏现象」 「Doublewrite Buffer」的大小是独立且固定的不是基于页的大小来划分的。所以不受操作系统中的页大小限制也不会发生「页损坏现象」。并且先以顺序IO的方式向「Doublewrite Buffer」写入数据页再以随机IO异步刷新到表空间这种方式还可以提高写入性能。 再看第二点为什么以日志的形式先刷新到磁盘
日志先行机制
在「Buffer Pool」中更新完数据页后由于不会及时将这些「脏页」刷新到磁盘为了避免数据丢失会将本次的DML操作向「Log Buffer」中写一份并且刷新到磁盘中相比16KB的数据页来说这个数据量会小很多而且写入日志文件时是追加操作属于顺序IO效率较高。如下图哪种方式写入效率更高是显而易见的。 这里说的日志文件就是经常会听到的「Redo Log」即使MySQL宕机了通过磁盘的redolog也可以在MySQL启动时尽可能的将数据恢复到宕机之前样子。当然还有「Undo Log」因为对本文重点没有直接影响所以不对此展开说明。
这种日志先行WAL的机制也是MySQL用于提高效率和保障数据可靠的一种方式。 为什么是尽可能的恢复 日志刷盘机制
因为「Log Buffer」中的日志数据什么时候向磁盘刷新则是由 innodb_flush_log_at_trx_commit 和 innodb_flush_log_at_timeout 这两个参数决定的。
innodb_flush_log_at_trx_commit默认为1也就是每次事务提交后就会刷新到磁盘。当innodb_flush_log_at_trx_commit设置为0时则不会根据事务提交来刷新而是根据innodb_flush_log_at_timeout设置的时间定时刷新这个时间默认为1秒。当innodb_flush_log_at_trx_commit设置为2时仅将日志写入操作系统中的缓存中随后跟随根据innodb_flush_log_at_timeout定时刷新。
如果在MySQL服务宕机的时候「Log Buffer」中的日志没有刷新到磁盘这部分数据也是会丢失的在重启后也不会恢复。所以如果不想丢失数据在性能还可以的情况下尽量将innodb_flush_log_at_trx_commit设置为1。 「redo log」是怎么恢复数据的 Redo Log 恢复数据
首先redo log会记录DML的操作类型、数据的表空间、数据页以及具体操作内容以 insert into t1(1,hi)为例对应的redo log内容大概这样的 假如 innodb_flush_log_at_trx_commit 的值为1那么当该DML操作事务提交后就会将 redo log 刷新到磁盘。成功刷新到磁盘后就可以视为数据被写入成功。
此时如果「脏页」还没刷新到磁盘便宕机那么在下次MySQL启动时便去加载redo log如果redo log存在数据则意味着需要恢复数据。这个时候就可以通过redo log中的内容重新构建「脏页」从而恢复到宕机之前的状态。 怎么构建「脏页」呢 其实在每次的redo log写入时都会记录一个「LSNlog sequence number」同时这个值在「数据页」中记录最后一次被修改的日志序列位置。MySQL在启动时通过LSN来对比 redo log 和数据页如果数据页中的LSN小于 redo log 的LSN则会将该数据页加载到「Buffer Pool」然后根据 redo log 的内容构建出「脏页」等待下次刷新到磁盘数据也就恢复了。如下图 注意这个恢复的过程重点在redo上实际上还涉及到「Change Buffer」、「Undo Log」等操作这里没有展开说明。 「Doublewrite Buffer」和「redo log」都是恢复数据的不冲突吗 不冲突「Doublewrite Buffer」是对「页损坏现象」的整个数据页进行恢复Redo Log只能对某次的DML操作进行恢复。
总结
InnoDB通过以上的操作可以尽可能的保证MySQL不丢失数据最后再总结一下MySQL是如何保障数据不丢失的
为了避免频繁与磁盘交互每次DML操作先在「Buffer Pool」中的缓存页中执行缓存页有更新之后便成为「脏页」随后根据innodb_max_dirty_pages_pct这个参数将「脏页」刷新到磁盘。因为「脏页」在刷新到磁盘之前可能会存在MySQL宕机等异常行为导致数据丢失所以MySQL采用日志先行WAL机制将DML操作以日志的形式进行记录到「Redo Log」中随后根据innodb_flush_log_at_trx_commit 和 innodb_flush_log_at_timeout这两个参数将「Redo Log」刷新到磁盘以便恢复。在向磁盘刷新「脏页」时为了避免发生「页损坏」现象InnoDB采用双写机制先将这些脏页顺序写入「Doublewrite Buffer」中随后再将数据页异步刷新到各个表空间中这种方式既能提高写入效率又可以保障数据的完整性。如果在「脏页」刷新到磁盘之前MySQL宕机了那么会在下次启动时通过 redo log 将脏页构建出来做到数据恢复。通过以上步骤MySQL做到了尽可能的不丢失数据。
