Mysql 日志（redolog, binlog, undoLog）

重做日志-redolog

是什么

innoDB存储引擎层面的日志，它的作用是当 数据更新过程中数据库发生异常导致提交的记录丢失

为什么

mysql的基本存储结构是页（记录都在页里面），所以更新语句时，mysql需要先把要更新的语句找到，加载进内存(buffer pool)，再修改对应的记录，再写会磁盘

此时就会面临问题：

1、如果内存中的数据更新了，但是未落入磁盘，mysql挂了怎么办？

2、每个请求都需要将数据立马落入磁盘，速度会很慢，mysql可能会顶不住

因此 Innodb引入了redolog

怎么做，实现原理

 

redolog也是需要写入磁盘的，但它是顺序写入的，顺序io比随机io快很多

目的：当我们修改了数据，写完内存了，可能还未落入磁盘，数据库挂掉了，此时可以根据redo log来恢复数据。redo log是顺序io，所以写入速度很快，记录的是物理变化(xx页做了xx修改)，文件体积小，所以恢复速度也快
 

• 内容：记录的是物理数据页面的修改信息（xx页做了xx修改），其redo log是顺序写入redo log fail的物理文件中去的
• 介绍一下：redolog又叫重做日志，是存储引擎层面的日志(innoDb特有的日志)，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来
• 日志大小是固定的，即写满了之后会从头开始循环写
• Innodb_log_file_size=100M(指定大小)；Innodb_log_files_in_group=5(指定个数)
   

归档日志-binlog

binlog（归档日志）：是mysql server层面的日志，属于逻辑日志，是以二进制形式记录的，记录的是这个语句的原始逻辑(每条变更的sql语句)，追加写的方式，即一份日志文件写到一定大小的时候会更换下一个文件，不会覆盖。

• 用于复制，在主从复制中，从库利用主库上的binlog进行传播，实现主从同步
• 用于数据库基于时间点的还原

回滚日志-undolog

undo log：在数据的修改过程中，会记录一条与当前操作相反的逻辑到undo log中，如果因为某些原因导致事务异常失败了，可以借助undo log进行回滚，保证事务的完整性

• 提供了回滚的作用，保证事务的原子性
• mvcc的实现

 

redolog 和bin log的区别

	bin log	redo log
实现层面	mysql server层实现的	innoDB存储引擎层面的
记录内容	记录的是逻辑日志（sql语句）	记录的是物理日志（xx页做了xx修改）
写入方式	追加写入，一个文件写完可以换一个文件接着写	循环写，空间大小固定，会覆盖
作用	用于主从复制，恢复数据	持久化
提交实际	事务提交时记录	事务开始时记录每次的变更信息

redolog是如何保证crash-safe的？

crash-safe是通过redo log的write ops和checkpoint机制来保证的

WAL（write ahead log）日志先行技术：先写日志，再写磁盘。对于数据更新操作，先写入redo log

redo log有两个关键的指针：write ops和checkpoint。write ops是当前记录的位置，一边写一边后移，无法移动的时候就回到开头。checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把数据更新到数据文件。write ops和checkpoint之间还空着的地方，可以用来记录新的操作，如果write ops追上了checkpoint，此时不能进行新的更新操作，需要停下来先擦除一部分内容
 

redolog 能保证crash-safe，还需要bin log吗？

看场景

• 主从模式下，binlog是需要的，因为从库同步主库的数据依赖于bin log
• 单机模式下，如果不考虑基于某个时间点数据的还原，可以不需要bin log。但是万一需要恢复某个时间点的数据，是做不到的，所以建议一直开启bin log

简言之，red log只有innodb有，别的存储引擎没有。redo log是循环写的，不持久保存，所以还是需要binlog。