数据库 undo log redo log bin 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)。

 

1. 每条数据变更(insert/update/delete)操作都伴随一条undo log的生成,并且回滚日志必须先于数据持久化到磁盘上
2. 所谓的回滚就是根据回滚日志做逆向操作，比如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最安全的是设置是1
• N：每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