数据库中的binlog、redolog、undolog的区别

binlog二进制日志是mysql-server层的,主要是做主从复制,时间点恢复使用
redo log重做日志是InnoDB存储引擎层的,用来保证事务安全
undo log回滚日志保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。select如果没有特定加锁的话就是快照读,用到了undolog,而insert delete和update都是当前读,与这个日志关系不大。

redo log

redo log在事务没有提交前,每一个修改操作都会记录变更后的数据,保存的是物理日志->数据
防止在发生故障的时间点,尚有脏页未写入磁盘,在重启mysql服务的时候,根据redo log进行重做,从而达到事务的持久性这一特性.
redo log只是先写入Innodb_log_buffer,定时fsync到磁盘

bin log

binlog只会在日志提交后,一次性记录执行过的事务中的sql语句以及其反向sql(作为回滚用),保存的是逻辑日志->执行的sql语句
undo log事务开始之前,将当前版本生成undo log,undo 也会产生 redo 来保证undo log的可靠性,保存的是逻辑日志->数据前一个版本

两者的区别

基于redo log直接恢复数据的效率 高于 基于binlog sql语句恢复
binlog不是循环使用,在写满或者重启之后,会生成新的binlog文件,redo log是循环使用。
binlog可以作为恢复数据使用,主从复制搭建,redo log作为异常宕机或者介质故障后的数据恢复使用。

两阶段提交

两阶段提交
最后,那么当我执行一条 update 语句时,redo log 和 binlog 是在什么时候被写入的呢?这就有了我们常说的「两阶段提交」:

写入:redo log(prepare)

写入:binlog

写入:redo log(commit)

为什么 redo log 要分两个阶段: prepare 和 commit ?redo log 就不能一次写入吗?

我们分两种情况讨论:

先写 redo log,再写 binlog

先写 binlog,再写 redo log

1、先写 redo log,再写 binlog

这样会出现 redo log 写入到磁盘了,但是 binlog 还没写入磁盘,于是当发生 crash recovery 时,恢复后,主库会应用 redo log,恢复数据,但是由于没有 binlog,从库就不会同步这些数据,主库比从库“新”,造成主从不一致

2、先写 binlog,再写 redo log

跟上一种情况类似,很容易知道,这样会反过来,造成从库比主库“新”,也会造成主从不一致

而两阶段提交,就解决这个问题,crash recovery 时:

如果 redo log 已经 commit,那毫不犹豫的,把事务提交

如果 redo log 处于 prepare,则去判断事务对应的 binlog 是不是完整的

是,则把事务提交

否,则事务回滚

两阶段提交,其实是为了保证 redo log 和 binlog 的逻辑一致性。

  • 8
    点赞
  • 49
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值