小米科技|一生挚友redo log、binlog《死磕MySQL系列 二》( 三 )


  • 那么此时的从库就会少这一次的更新 , 恢复出来的age依然是25 , 造成于主库数据不一致 。
  • 先写binlog后写redo log
    • 更新语句为age = age +1
    • 将数据写入binlog , MySQL异常重启
    • 此时redo log 还没写
    • MySQL系统重启 , 这个更新操作是对于redo log是不存在的 , 所以重启后的值依然是25
    • 但binlog 中的值已将是26了
    • 需要搭建从库时 , 从库的值是26 , 主库的值是25 , 造成主从数据不一致
    所以说 , 如果不使用两阶段提交 , 那么原库和用它的binlog日志恢复出来的库数据是不一致的 。
    五、《孔乙己》让你明白redo log是什么来看一个初中九年级语文课文中《孔乙己》这篇文章 , 就算不记得内容 , 标题总记得哈!
    这个案例也是看丁老师文章中提到的 , 为什么丁老可以灵活的使用这个案例来讲redo log而我们想不到呢?
    其本质原因是对知识点没有理解透彻 , 使用生活案例来解释技术是让人最容易理解并不难遗忘的 。
    《孔乙己》中的主人公就叫他酒店掌柜 , 掌柜的有俩件法宝让比其他老板工作效率高很多 。 一个是小黑板另一个是账本 。
    试想一下如果有客人要赊账 , 是直接写到黑板效率高 , 还是翻密密麻麻的账本来的快呢?
    掌柜肯定会选择先记录到黑板上 , 等人少或者不忙时再把黑板的记录写到账本中 。
    反之老板没有黑板的话 , 只能在密密麻麻的账本中先找到赊账人的名字 , 如果之前有赊账记录追加 , 找了一遍发现没有才进行新增 。
    这个过程不仅繁琐而且效率低的让人难以接受 , 如果酒店客人多老板是记录不过来的 。
    同样 , 在MySQL中也会存在这个问题 , 每次执行更新语句都需要先找到那条记录 , 然后再更新 , 整个过程IO成本、查找成本都很高 。 所以MySQL也利用了酒店掌柜的智慧使用黑板来提升执行效率 。
    画一幅图让大家能更好的理解掌柜、黑板、在MySQL中的对应关系 。
    六、redo log参数详解事务的持久性就是通过重做日志来实现的 。
    当提交事务之后 , 并不是直接修改数据库的数据的 , 而是先保证将相关的操作记录到redo日志中 。
    数据库会根据相应的机制将内存的中的脏页数据刷新到磁盘中 。
    上图是一个简单的重做日志写入流程 。
    在上图中提到俩个陌生概念 , Buffer pool、redo log buffer , 这个俩个都是Innodb存储引擎的内存区域的一部分 。
    而redo log file是位于磁盘位置 。
    也就说当有DML(insert、update、delete)操作时 , 数据会先写入Buffer pool , 然后在写到重做日志缓冲区 。
    重做日志缓冲区会根据刷盘机制来进行写入重做日志中 。
    这个机制的设置参数为innodb_flush_log_at_trx_commit , 参数分别为01 , 2
    上图即为重做日志的写入策略 。
    • 当这个参数的值为0的时 , 提交事务之后 , 会把数据存放到redo log buffer中 , 然后每秒将数据写进磁盘文件
    • 当这个参数的值为1的时 , 提交事务之后 , 就必须把redo log buffer从内存刷入到磁盘文件里去 , 只要事务提交成功 , 那么redo log就必然在磁盘里了 。
    • 当这个参数的值为2的情况 , 提交事务之后 , 把redo log buffer日志写入磁盘文件对应的os cache缓存里去 , 而不是直接进入磁盘文件 , 1秒后才会把os cache里的数据写入到磁盘文件里去 。
    服务器异常停止对事务如何应对(事务写入过程)
    • 当参数为0时 , 前一秒的日志都保存在日志缓冲区 , 也就是内存上 , 如果机器宕掉 , 可能丢失1秒的事务数据 。
    • 当参数为1时 , 数据库对IO的要求就非常高了 , 如果底层的硬件提供的IOPS比较差 , 那么MySQL数据库的并发很快就会由于硬件IO的问题而无法提升 。
    • 当参数为2时 , 数据是直接写进了os cache缓存 , 这部分属于操作系统部分 , 如果操作系统部分损坏或者断电的情况会丢失1秒内的事务数据 , 这种策略相对于第一种就安全了很多 , 并且对IO要求也没有那么高 。
    小结
    关于性能:0>2>1
    关于安全:1>2>0
    根据以上结论 , 所以说在MySQL数据库中 , 刷盘策略默认值为1 , 保证事务提交之后 , 数据绝对不会丢失 。