MySQl中redo log和binlog的区别

使用MySQL数据库的时候通常会听说有日志系统,最常听说的就是redolog和binlog,那么两种日志有什么不同呢。

首先,两个的层次不一样,学过MySQL的小伙伴都知道MySQL逻辑分层中有着 服务层(Server)和数据库引擎层,其中binlog就是服务层的功能,而redolog则是innodb这个数据库引擎自己的功能,逻辑结构如图所示:

image.png

 其次在存储方面,虽然两者都是采用写入磁盘的数据结构,但是两个的方式并不一样。其中redolog采用一个类似环形存储区的方式进行存储,也就是有大小限制(my.cnf 中 innodb_log_file_size 用来设定redolog大小),一旦写到尾部则从新覆盖头部继续写;binlog则采用rotate分片的形式记录日志,可以不断追加,如果不特意配置则没有大小限制。

The redo log is a disk-based data structure used during crash recovery to correct data written by incomplete transactions. 

Redolog有两个关键的位置点(position),其中write position就是从这个地方继续追加新的日志,而check point 则是将redo日志写回磁盘到达的位置,从write position到 checkpoint两者之间的空间就是剩余的可追加日志空间。如果write position已经追上了checkpoint,那就要求数据库引擎innodb赶紧将内容写回磁盘后才能记录写redolog。

image.png

再者存储格式和方法也不尽相同,binlog虽然叫做bin(以二进制形式存储),但是实际存储的是逻辑操作过程,也就是比如 insert into user id,username values(3,'root') 这种形式,而redolog更像是磁盘上发生的变化。

功能类似但不完全相同,binlog用于记录整个历史记录,而redolog虽然也能用于恢复,但是设计之初的主要目的是缓存未提交的修改,比如我们update user set gender='famele' where username like '%lucy'  ,可能需要扫描很多行并且有很多行需要修改,如果直接去修改磁盘可能有性能问题,不如先把要操作的记录写到redolog之中,然后就可以返回已经更新完成,然后在空闲时间慢慢写回磁盘即可。

redolog的工作路程

redolog的基本工作流程,先写入redolog,写入完成返回给客户端写入成功,然后redolog再写回到磁盘,因此再写完redolog系统崩溃或者mysql进程崩溃,数据是不会丢失是可以恢复的。

两阶段提交

更新数据写入redolog,这时候的这个日志是 prepare状态,然后执行器生成binlog日志,并把binlog写入磁盘完成后,执行器调用数据库存储引擎的事务提交接口,引擎现在从prepare状态改成commit状态,于是更新完成。

两阶段提交可以保证binlog和redolog的一致性,避免恢复的时候使用不同日志导致数据不一致的问题。

0 0 vote
Article Rating
此条目发表在MySQL分类目录,贴了, , 标签。将固定链接加入收藏夹。
Subscribe
提醒
guest
0 评论
Inline Feedbacks
View all comments