MySQL日志

MySQL日志

一、redo log 日志

1.1、基本概念

redo log包括两部分：一是内存中的日志缓冲（redo log buffer），该部分日志是易失性的；二是磁盘上的重做日志文件（redo log file），该部分日志是持久的。
为了确保每次日志都能写入到事务日志文件中，在每次将log buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作（即fsync()系统调用）。因为 MariaDB/MySQL 是工作在用户空间的，MariaDB/MySQL 的log buffer处于用户空间的内存中。要写入到磁盘上的log file中（redo:ib_logfileN文件、undo:share tablespace或.ibd文件），中间还要经过操作系统内核空间的os buffer，调用fsync()的作用就是将os buffer中的日志刷到磁盘上的log file中。

1.2、具体操作过程

1.3、存储形式

在 InnoDB 存储引擎中，redo log是以块(redo log block)为单位进行存储的，每个块占 512 字节，这称为redo log block。所以不管是log buffer中还是os buffer中以及redo log file on disk中，都是这样以 512 字节的块存储的。
每个redo log block由 3 部分组成：日志块头、日志块尾和日志主体。其中日志块头占用 12 字节，日志块尾占用 8 字节，所以每个redo log block的日志主体部分只有512 - 12 - 8 = 492字节。

因为redo log记录的是数据页的变化，当一个数据页产生的变化需要使用超过 492 字节的redo log来记录，那么就会使用多个redo log block来记录该数据页的变化。

1.4、日志的格式

因为 InnoDB 存储引擎存储数据的单元是页（和 SQL Server 中一样），所以redo log也是基于页的格式来记录的。默认情况下，InnoDB 的页大小是 16KB（由innodb_page_size变量控制），一个页内可以存放非常多的log block（每个 512 字节），而log block中记录的是数据页的变化。其中，log block中 492 字节的部分是log body，该log body的格式分为 4 部分:

• redo_log_type：占用 1 个字节，表示redo log的日志类型。

• space：表示表空间的 ID，采用压缩的方式后，占用的空间可能小于 4 字节。

• page_no：表示页的偏移量，同样是压缩过的。

• redo_log_body：表示每个重做日志的数据部分，恢复时会调用相应的函数进行解析。例如insert语句和delete语句写入redo log的内容是不一样的。

1.5、日志的作用

redo log是InnoDB存储引擎层的日志，又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。

在一条更新语句进行执行的时候，InnoDB引擎会把更新记录写到redo log日志中，然后更新内存，此时算是语句执行完了，然后在空闲的时候或者是按照设定的更新策略将redo log中的内容更新到磁盘中，这里涉及到WAL即Write Ahead logging技术，他的关键点是先写日志，再写磁盘。

有了redo log日志，那么在数据库进行异常重启的时候，可以根据redo log日志进行恢复，也就达到了crash-safe。

redo log日志的大小是固定的，即记录满了以后就从头循环写

二、undo log

2.1、概念

undo log有两个作用：提供回滚和多个行版本控制(MVCC)。

在数据修改的时候，不仅记录了redo，还记录了相对应的undo，如果因为某些原因导致事务失败或回滚了，可以借助该undo进行回滚。

undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。

当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。

undo log是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment。

另外，undo log也会产生redo log，因为undo log也要实现持久性保护。

2.2存储格式

InnoDB 存储引擎对undo log的管理采用段的方式。rollback segment称为回滚段，每个回滚段中有 1024 个undo log segment。

在以前老版本，只支持 1 个rollback segment，这样就只能记录 1024 个undo log segment。后来 MySQL5.5 可以支持 128 个rollback segment，即支持128*1024个undo操作，还可以通过变量 innodb_undo_logs （MySQL5.6 版本以前该变量是innodb_rollback_segments）自定义多少个rollback segment，默认值为 128

2.3 delete/update操作的内部机制

当事务提交的时候，innodb不会立即删除undo log，因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。

但是在事务提交的时候，会将该事务对应的undo log放入到删除列表中，未来通过purge来删除。并且提交事务时，还会判断undo log分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的undo log页而浪费存储空间和性能。

通过undo log记录delete和update操作的结果发现：(insert操作无需分析，就是插入行而已)

delete操作实际上不会直接删除，而是将delete对象打上delete flag，标记为删除，最终的删除操作是purge线程完成的。
update分为两种情况：update的列是否是主键列。
如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
如果是主键列，update分两部执行：先删除该行，再插入一行目标行。