Redo&Undo&Binlog

2

0

Undo Log File

read

内存

fsync()

参考资料：https://www.cnblogs.com/f-ck-need-u/p/9010872.htmlhttps://www.cnblogs.com/fanBlog/p/11017690.htmlhttps://worktile.com/kb/p/21710

commit

Log File

OSBuffer

Kernel Space

Undo Log Buffer

master db

write

User Space

每秒写入OS Buffer，并调用fsync()刷新到磁盘

Undo Log属于逻辑日志，它记录的是sql执行相关的信息，提供回滚操作和多版本并发控制（MVCC）。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也要实现持久性保护。

Buffer Pool

MySQL支持用户自定义在commit时如何将log buffer中的日志刷log file中。这种控制通过变量 innodb_flush_log_at_trx_commit 的值来决定。该变量有3种值：0、1、2，默认为1。但注意，这个变量只是控制commit动作是否刷新log buffer到磁盘。0              事务提交时不会将log buffer中日志写入到os buffer，而是每秒写入os buffer并调用fsync()写入到                 log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟的                 数据。1              事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种方式即                使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO的性能较差。2              每次提交都仅写入到os buffer，然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。

redo log不是二进制日志。虽然二进制日志中也记录了innodb表的很多操作，也能实现重做的功能，但是它们之间有很大区别。1. 二进制日志是在存储引擎的上层产生的，不管是什么存储引擎，对数据库进行了修改都会产生二进制日志。而redo log是innodb层产生的，只记录该存储引擎中表的修改。并且二进制日志先于redo log被记录。具体的见后文group commit小结。2. 二进制日志记录操作的方法是逻辑性的语句。即便它是基于行格式的记录方式，其本质也还是逻辑的SQL设置，如该行记录的每列的值是多少。而redo log是在物理格式上的日志，它记录的是数据库中每个页的修改。3. 二进制日志只在每次事务提交的时候一次性写入缓存中的日志\"文件\

OS Buffer

Redo Log & Bin Log 区别

sql thread

relay log

Bin Log

Redo Log属于物理日志，它记录的是数据库中每个页的修改，用来确保事务的持久性。事务日志InnoDB使用日志来降低提交事务的成本。它不会在每个事务提交时将缓冲池刷新到磁盘，而是将事务记录到日志中。事务对数据和索引所做的更改通常映射到表空间中的随机位置，因此将这些更改刷新到磁盘将需要随机I/O。InnoDB假定它使用的是传统的磁盘，随机I/O比顺序I/O的开销要大很多，因为随机I/O需要在磁盘上寻找正确的位置，并等待将所需的磁盘部分旋转到磁头下。使用日志，InnoDB可以将随机磁盘I/O转换为顺序I/O。一旦日志被安全地保存在磁盘中，即使更改的数据尚未写入数据文件，事务仍将是持久的。如果发生故障（例如停电），InnoDB可以重放日志并恢复已提交的事务。当然，InnoDB最终必须将更改的数据写入数据文件，因为日志的大小固定，采取的是循环写入的方式：当到达日志的末尾时，它会环绕日志的开头。如果日志记录中包含的更改尚未应用于数据文件，则无法覆盖日志记录，因为这将删除已提交事务的唯一永久记录。InnoDB使用后台线程智能地刷新对数据文件的更改。该线程可以将写入分组，并使数据写入顺序化，以提高效率。实际上，事务日志可以将随机数据文件I/O转换为顺序日志文件I/O和顺序数据文件I/O。将刷新移到后台可以更快地完成查询，并有助于缓冲I/O系统的查询负载峰值。默认情况下，对应的物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2b style=\

bin log

每秒调用fsync()刷新到磁盘

slave db

Redo Log File

Disk File

每次提交写入OS Buffer，并调用fsync()刷新到磁盘

1

Log Buffer

InnoDB Engine

每秒写入OS Buffer

Redo Log

磁盘

Redo Log Buffer

replay

Undo Log

IO thread

sql dump thread

Bin Log属于二进制日志文件，它记录了数据库所有执行的更新语句，主要用于数据恢复和数据复制。数据恢复：如果MySQL意外停止，可以通过该日志进行恢复，备份数据复制：master把它的二进制日志传递给slaves来达到master-slave数据的一致性