MySQL日志系统

MySQL相关文章

• 慢sql搜集分析工具搭建

前言

日志系统可谓是MySQL中的重中之重，一些MySQL的特性也通过依赖于日志实现的。

本篇文章过一遍日志相关的东西，方便日后复习。

binlog

概念

• 二进制日志文件，记录了所有的DDL（数据库定义语言，create、alter、drop）和DML（数据库操作语言，select、update、insert、delete）语句，以事件形式记录，包含语句所执行的消耗的时间。

• 用作于主从架构下的数据同步，也可以用作误删操作后基于binlog恢复到指定时间点。通过自带的mysqlbinlog命令恢复。

• 两阶段提交时也会依赖binlog实现事务数据一致。

存储规则

• binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。

• 配置文件的路径为log_bin_basename，binlog日志文件按照指定大小，当日志文件达到指定的最大的大小之后，进行滚动更新，生成新的日志文件。对于每个binlog日志文件，通过一个统一的index文件来组织。
  

redolog

概念

• 重做日志，主要记录事务执行后的状态，用来恢复未写入磁盘的已成功事务更新的数据。

  • 数据库对数据做修改时会将磁盘中的数据加载到buffer pool中，然后再buffer pool中修改，这时内存中的数据与磁盘数据不一致成为脏页
  • 如果这时候db发生重启，这些数据由于还在内存中未同步到磁盘中(随机io)，会发生数据丢失
  • 为了避免这种现象，当buffer pool的数据发生变化结束后把相应修改记录保存在redolog文件中
  • 当db发生崩溃时恢复的时候，可以根据这个文件的记录内容，重新应用到磁盘文件，数据保持一致。

• redolog是innodb引擎独有的日志

存储规则

• 数据空间有限，循环写入，write pos表示当前位置，一边写一遍后移，checkpoint表示要清除的位置
• 记录对数据的修改操作，主要目的是的随机IO变成顺序IO，提升性能。
• redolog没有记录完整数据，真正落盘不需要redolog，等到merge时直接将buffer pool持久化到磁盘

与binlog的区别

• redolog属于引擎层日志是innodb引擎特有，binlog属于server层日志。
• redolog是物理日志，记录了是“哪个会话哪个时间在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑sql，比如"给 ID=2 这一行的 c 字段加 1"
• redolog是循环写入有最大限制，binlog可以追加，不会覆盖之前的日志。

两阶段提交

• MySQL为了保证数据安全，数据所有操作都是先写日志再写磁盘
• 整个写入逻辑划分成 redolog prepare -> binlog -> redolog commit
• 校验数据
  1. binlog有记录，redolog commit: 正常事务
  2. binlog有记录，redolog prepare: 写入库成功，提交事务
  3. binlog无记录，redolog prepare: 写入数据库失败，回滚事务

undolog

概念

• 回滚日志，用于存放数据被修改前的值，如果修改异常可以使用undo日志来实现回滚操作，保证事务的一致性。
• 用于MySQL实现事务原理与MVCC特性
• undolog分为
  1. insert undolog， insert语句产生的的日志，事务提交后
  2. update undolog， delete和update语句产生的日志，事务提交后放到history list中，等待purge线程进行最终删除

changebuffer

概念

• 当需要更新数据时，如果数据在内存中则直接更新，如果不在innodb会把更新操作缓存在changebuffer中，当下次需要访问这条数据时，将这条数据从磁盘加载到内存并执行change buffer的逻辑，减少随机读的IO的消耗。
• 主要目的节省随机读磁盘的io消耗，合并多次操作为批操作提高性能。

原理

• changebuffer也会落盘，将changebuffer的的操作合并到原数据页得到新结果的过程叫做merge
• merge过程
  • 磁盘读入数据
  • 将changebuffer内容依次应用到内存
  • 写入redolog，数据变化