您好,登录后才能下订单哦!
小编给大家分享一下Mysql中undo、redo与binlog的区别有哪些,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!
MySQL中有六种日志文件,分别是:重做日志(redo log)、回滚日志(undo log)、二进制日志(binlog)、错误日志(errorlog)、慢查询日志(slow query log)、一般查询日志(general log),中继日志(relay log)。
其中重做日志和回滚日志与事务操作息息相关,二进制日志也与事务操作有一定的关系,这三种日志,对理解MySQL中的事务操作有着重要的意义。
与不同引擎的关系 | 核心作用 | 生命周期 | 日志类型 | |
undo log | 属于innodb引擎独有 | 回滚,保证事务的“原子性”,事务日志 | 事务开始前,以类似“快照”的方式记录现场 | 逻辑日志 |
redo log | 属于innodb引擎独有 | 重做,保证事务的“持久性”,事务日志 | 事务开始后记录,prepare阶段落盘 | 物理日志 |
binlog | 工作在mysql的Server层,与使用哪种引擎无关 | 实现主从节点数据的复制 | 事务执行期间记录,commit阶段完成前落盘 | 逻辑日志 |
事务开始之前,将当前事务版本生成 undo log(Tips:undo log 也会产生 redo log 来保证 undo log 的可靠性)。
事务提交之后,undo log 并不能立马被删除,而是放入待清理的链表,由 purge 线程判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息,从而决定是否可以清理 undo log 的日志空间。
数据库事务四大特性中有一个是 原子性 ,具体来说就是 原子性是指对数据库的一系列操作,要么全部成功,要么全部失败,不可能出现部分成功的情况。
实际上, 原子性 底层就是通过undo log实现的。undo log主要记录了数据的逻辑变化,比如一条INSERT语句,对应一条DELETE的undo log,对于每个UPDATE语句,对应一条相反的UPDATE的undo log,这样在发生错误时,就能回滚到事务之前的数据状态。例如,user表中原记录如下:
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是如何保证事务的持久性的呢?最简单的做法是在每次事务提交的时候,将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题,主要体现在两个方面:
因为Innodb是以页为单位进行磁盘交互的,而一个事务很可能只修改一个数据页里面的几个字节,这个时候将完整的数据页刷到磁盘的话,太浪费资源了!
一个事务可能涉及修改多个数据页,并且这些数据页在物理上并不连续,使用随机IO写入性能太差!
因此,mysql设计了redo log机制,并通过WAL(Write-Ahead Logging)技术进行了性能优化。WAL的核心就是先顺序IO写日志磁盘、再随机IO写数据磁盘,节省的是随机写磁盘的 IO 消耗。mysql 每执行一条 DML 语句,先将记录顺序追加写入 redo log buffer并更新内存中的数据,等到有空闲线程、内存不足、Redo Log满时再批量落盘持久化。
binlog是mysql的逻辑日志并且由Server层进行记录,记录对象为任意数据库引擎的写入性操作(不包括查询)信息,以二进制的形式保存在磁盘中。
在实际应用中,binlog的主要使用场景有两个,分别是 主从复制 和 数据恢复 。
主从复制 :在Master端开启binlog,然后将binlog发送到各个Slave端,Slave端重放binlog从而达到主从数据一致。
数据恢复 :通过使用mysqlbinlog工具来恢复数据。
数据更新过程中,万一更新数据的过程中系统出现故障异常重启了,如何保证事务的持久性、原子性呢?概述如下:
记录此次更新前数据记录的快照现场(即写undo log)
读取此次更新所需要的数据入内存
在内存中更新数据(效率高)
写redo log,并置redo log状态为prepare
写binlog
置redo log状态为commit
基于上述简化版的undo log、redo log和binlog的写入流程,我们来梳理下原子性、持久性、一致性的可靠性保证:
A)假如是在步骤1/2/3中任一步骤发生故障,故障恢复后发现redo log中并无未完成的记录,故障恢复后只需要回滚undo log恢复现场即可;
B)假如在步骤4/5中任一步骤发生故障,故障恢复后发现redo log处于prepare状态,则进一步判断是否已经写入binlog:
若已经写入binlog,则重新执行redo log的相关记录直到成功达到commit状态(主从的一致性);
若未写入binlog,则回滚undo log恢复现场(原子性);
C)假如在步骤6发生故障,故障恢复后发现redo log处于commit状态,表示过程全部正常完成,则什么都不需要做。
以上是“Mysql中undo、redo与binlog的区别有哪些”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。