在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
前言MySQL中有六种日志文件,分别是:重做日志(redo log)、回滚日志(undo log)、二进制日志(binlog)、错误日志(errorlog)、慢查询日志(slow query log)、一般查询日志(general log),中继日志(relay log)。 其中重做日志和回滚日志与事务操作息息相关,二进制日志也与事务操作有一定的关系,这三种日志,对理解MySQL中的事务操作有着重要的意义。
【undo log】
|
id | name |
1 | xiaoming |
执行sql update user set name = 'xiaohong' where id = 1;
的时候生成的undo log大概是update user set name = 'xiaoming' where id = 1;
同时,undo log也是MVCC(多版本并发控制)实现的关键。
mysql是如何保证事务的持久性的呢?最简单的做法是在每次事务提交的时候,将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题,主要体现在两个方面:
因此,mysql设计了redo log机制,并通过WAL(Write-Ahead Logging)技术进行了性能优化。WAL的核心就是先顺序IO写日志磁盘、再随机IO写数据磁盘,节省的是随机写磁盘的 IO 消耗。mysql 每执行一条 DML 语句,先将记录顺序追加写入 redo log buffer并更新内存中的数据,等到有空闲线程、内存不足、Redo Log满时再批量落盘持久化。
binlog是mysql的逻辑日志并且由Server层进行记录,记录对象为任意数据库引擎的写入性操作(不包括查询)信息,以二进制的形式保存在磁盘中。
在实际应用中,binlog的主要使用场景有两个,分别是 主从复制 和 数据恢复 。
数据更新过程中,万一更新数据的过程中系统出现故障异常重启了,如何保证事务的持久性、原子性呢?概述如下:
基于上述简化版的undo log、redo log和binlog的写入流程,我们来梳理下原子性、持久性、一致性的可靠性保证:
A)假如是在步骤1/2/3中任一步骤发生故障,故障恢复后发现redo log中并无未完成的记录,故障恢复后只需要回滚undo log恢复现场即可;
B)假如在步骤4/5中任一步骤发生故障,故障恢复后发现redo log处于prepare状态,则进一步判断是否已经写入binlog:
C)假如在步骤6发生故障,故障恢复后发现redo log处于commit状态,表示过程全部正常完成,则什么都不需要做。
到此这篇关于Mysql中undo、redo与binlog区别的文章就介绍到这了,更多相关Mysql中undo、redo与binlog区别内容请搜索极客世界以前的文章或继续浏览下面的相关文章希望大家以后多多支持极客世界!
请发表评论