MySQL之binlog日志、undo日志、redo日志

MySQL, 数据库 / 作者：
一、MySQL常用的几种日志
MySQL主要包含以下几种日志：

  • 错误日志
  • 查询日志
  • 慢查询日志
  • 事务日志 [undo日志(回滚日志)、redo日志(重做日志)]
  • 二进制日志（binlog日志）

本章主要介绍binlog日志、undo日志、redo日志

二、binlog日志

1. 什么是binlog?

在MySQL的基本架构这篇文章中，我们分享了MySQL的基础架构，其中，binlog日志属于Server层的日志，只能用于归档，没有carsh-safe能力。

MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。

2. binlog的作用

  • 主从备份：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到主从数据一致的目的。
  • 数据恢复：通过使用mysqlbinlog工具来使恢复数据。

3. binlog的日志格式

  • 语句(statement)：默认的记录格式，每一条会修改数据的sql都会记录在binlog中
    优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。)
    缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).
    使用以下函数的语句也无法被复制：
    LOAD_FILE()
    UUID()
    USER()
    FOUND_ROWS()
    SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
    同时在INSERT …SELECT 会产生比 RBR 更多的行级锁
  • 行(row)：不记录sql语句上下文相关信息，仅保存哪条记录被修改
    优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
    缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
  • 混合模式(mixed)：是以上两种level的混合使用。
    一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。
    Mixed日志说明：
    在slave日志同步过程中，对于使用now这样的时间函数，MIXED日志格式，会在日志中产生对应的unix_timestamp()*1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。

三、redo日志

1. 什么是redo日志？

  • redo log叫做重做日志，是用来实现事务的持久性。
  • 该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log），前者是在内存中，后者在磁盘中。
  • 当事务提交之后会把所有修改信息都会存到该日志中。
  • 是InnoDB引擎独有的日志，属于存储引擎层日志
  • redo log的大小是固定的，如下图：

说明：
write pos是当前记录的位置，一边写一边后移，写到末尾又从头开始
check point是当前要擦除的位置，同样也是往后移动并且循环，擦除记录，先把日志更新到磁盘中

假设有两张表，如下图：

现在要从银行卡账户转400块到理财账户中，事务过程如下：

start transaction;
select balance from bank where name="zhangsan";
// 生成 重做日志 balance=600
update bank set balance = balance - 400; 
// 生成 重做日志 amount=400
update finance set amount = amount + 400;
commit;

上述事务流程图如下：

事务流程图

2. redo log 有什么作用？

mysql 为了提升性能不会把每次的修改都实时同步到磁盘，而是会先存到Boffer Pool(缓冲池)里头，把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。

问题：
但随之二来的问题是，如果还没来的及同步就发生宕机或断电怎么办？上面图中红色的操作还没来得及执行，这样会导致丢失部分已提交事务的修改信息！

解决方法：
引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘，系统重启之后在读取redo log恢复最新数据。

四、undo日志

1. 什么是undo日志？

  • undo log 叫做回滚日志，用于记录数据被修改前的信息。
  • 正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息，undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。

还用上面那两张表，如下图：

每次写入数据或者修改数据之前都会把修改前的信息记录到 undo log。

2. undo log 有什么作用？

undo log 记录事务修改之前版本的数据信息，因此假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。

五、一条更新语句的执行流程（日志两段提交）

通过日志两阶段提交，可以保证redo log和bin log的逻辑一致

六、redo log跟bin log的区别

  • redo log是InnoDB特有的；
    binlog是Server层实现的，所有存储引擎都可以使用
  • redo log是物理日志，记录“某个数据页上的修改”；
    binlog是逻辑日志，记录语句的原始逻辑
  • redo log是循环写的，空间固定；
    binlog是可以追加写入的，不会覆盖以前的日志

发表评论