数据库 undo log redo logbin log

 

逻辑日志：可以简单理解为记录的就是sql语句物理日志：因为mysql数据最终是保存在数据页中的，物理日志记录的就是数据页变更

undo log 记录逻辑日志，是InnoDB存储引擎的日志

redo log 记录物理日志，是InnoDB存储引擎的日志

binlog 是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志

redo log是循环写入，bin log是追加写入，不会覆盖之前的日志。

 

在计算机操作系统中，用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。因此，redo log buffer写入redo log file实际上是先写入OS Buffer，然后再通过系统调用fsync()将其刷到redo log file中，过程如下：

 

 

1.redo log

redo log包括两部分：一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo log file)。mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。为了实现事务的持久性

持久化策略（innodb_flush_log_at_trx_commit参数配置）

0：事务提交的时候不会将redo log 中的数据写入到os buffer，而是每秒写入到os buffer,并通过系统调用fsync()写入到redo log file中。每秒落地一次，性能最高，数据一致性最差，如果mysql崩溃可能丢失一秒的数据1：事务每次提交都会将redo log buffer 中的数据写入到os buffer 中并通过系统调用fsync()写入到redo log file中。性能最差，一致性最高2：事务每次提交都会将redo log buffer 中的数据写入到os buffer ，然后每秒通过os buffer中的日志写入到redo log file 。性能好，安全性也高，只要os不宕机就能保证数据一致性

 

redo log 循环写入

redo log大小固定，配置为一组4个文件。write_pos是当前记录的位置，checkpoint是需要擦除的位置，擦除前将记录更新到数据文件。相当于一个循环队列，如果队列写满，需要先暂定，将checkpoint向前推荐一段空间，再进行写入。

数据更新流程

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

为了让两份日志逻辑一致，上述操作使用了二阶段提交

阶段1：InnoDB redo log 写盘，InnoDB 事务进入 prepare 状态

阶段2：如果前面prepare成功，binlog 写盘，那么再继续将事务日志持久化到binlog，如果持久化成功，那么InnoDB 

 

2.undo log

undo log有两个作用：

提供回滚多个行版本控制(MVCC)。

 

每条数据变更(insert/update/delete)操作都伴随一条undo log的生成,并且回滚日志必须先于数据持久化到磁盘上所谓的回滚就是根据回滚日志做逆向操作，比如delete的逆向操作为insert，insert的逆向操作为delete，update的逆向为update等。

 

MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。

InnoDB的 MVCC ，是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列， 一个保存了行的创建时间，一个保存了行的过期时间， 当然存储的并不是实际的时间值，而是系统版本号。

原理：通过数据多版本来做到读写分离。从而实现不加锁读进而做到读写并行。

MVCC在mysql中的实现依赖的是undo log与read view

undo log :undo log 中记录某行数据的多个版本的数据。

read view :用来判断当前版本数据的可见性

3.binlog

binlog使用场景

主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。数据恢复：通过使用mysqlbinlog工具来恢复数据。

binlog刷盘时机（sync_binlog参数）

对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中。

0：不去强制要求，由系统自行判断何时写入磁盘1：每次commit的时候都要将binlog写入磁盘，sync_binlog最安全的是设置是1N：每N个事务，才会将binlog写入磁盘

binlog日志格式

STATMENT：基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。

优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 从而提高了性能；缺点：在某些情况下会导致主从数据不一致，比如执行sysdate()、slepp()等。

ROW：基于行的复制(row-based replication, RBR)，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了。

优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题；缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨

MIXED：基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog