mysql日志

mysql的日志大体上需要了解的有三种
binlog,redo log,undolog

binlog

我们知道binlog在mysql中扮演的角色其实是类似备份一样的模块，并且它备份的方式是 逻辑备份

  • 逻辑备份 ： 只需要保存下系统操作的指令 而不是物理磁盘地址

    刷盘时机

    由于binlog文件时存储在磁盘中的，因此就需要定制刷盘的策略 大体上分为0~n

  • 0 设置为0表示刷盘的时机由cpu决定

  • 1 设置为1表示每一次commit就会刷盘

  • n 设置为n表示每执行N次事务就执行刷盘策略

    保存策略

    保存逻辑存储也是分为不同的方式

  • statment level

这一种方式同步表示每一次sql语句都会同步到文件中
优点 : 这一种方式只需要保存比较少的日志就可以做到备份数据的效果
缺点 ：某一些函数执行在主从可能造成超出预期的效果，不能到达主从一致的目标

  • row

这一种方式表示只会保存每一行的上下文数据 也就是每一条数据的变化状态
优点：这一种方式不会出现无法复制的情况，可以正确备份函数和触发器
缺点： 由于需要记录每一行数据的变化情况，如果出现全表操作，那么产生的日志是非常大的

  • mixed

这一种就是混合，默认使用tatment模式 当这一种模式保存不了，那么就使用raw模式
image.png

redo log

负责acid 中的d 持久性
记录事务对数据页做了哪些修改

WAL 【预日志记录】

write-ahead logging 先写入日志在写入磁盘
每执行一条dml语句先写入redo log buffe 【日志缓存】后续某一个时间点在一次性将多个操作记录写入到redo log file【日志文件】
日志缓冲 ： 存储在内存中的日志缓冲
日志文件 ： 存储在磁盘中的日志文件
image.png

刷盘策略

  • 0 【延迟写】 事务提交的时候不会讲redo log buffer 中日志写入到so buffer ,而是每一秒写入so buffer 斌且调用fsync() 写入到redo log file 中，也就是设置为0的时候 大约每秒写入到磁盘中的，当系统崩溃，也就只会丢失一秒的数据
  • 1 【实时写，实时刷】 事务每一提交都会讲redo log buffer 中的日志写入os buffer 并且调用fsync() 刷盘到redo log file 中，这种方式即使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO的性能较差。
  • 2 【实时写，延迟刷】 每次提交写入到os buffer ,然后每秒提交fsync() 将os buffer 中的日志写入到redo log file
  • image.png

    总结

    redo log 是需要刷盘的，并且数据页也是需要刷盘，redo log 存在的意义就是降低对数据页刷盘的要求。