undolog redolog binlog

redo和binlog区别:

1、首先2者都是记录数据的改变,不同的是,binlog是记录所有数据的改变信息,而innodb的redo log只是记录所有innodb表数据的变化。

2、binlog是记录已经提交完毕之后的dml以及ddl sql语句,而innodb redo log是正在执行中的dml以及ddl语句

3、binlog可以作为恢复数据使用 redo log可以作为异常down机或者介质故障后的数据恢复使用

4、在db文件目录下,也分属于不通的日志文件中。

undo log 实现原子性和持久化的事务的简化过程

假设有A、B两个数据,值分别为1,2。

A.事务开始.

B.记录A=1到undolog.

C.修改A=3.

D.记录B=2到undolog.

E.修改B=4.

F.将undolog写到磁盘。

G.将数据写到磁盘。

H.事务提交

Undo+Redo

事务的简化过程

假设有A、B两个数据,值分别为1,2.

A.事务开始.

B.记录A=1到undolog.

C.修改A=3.

D.记录A=3到redolog.

E.记录B=2到undolog.

F.修改B=4.

G.记录B=4到redolog.

H.将redolog写入磁盘。

I.事务提交

Undo+Redo

事务的特点

A.为了保证持久性,必须在事务提交前将RedoLog持久化。

B.数据不需要在事务提交前写入磁盘,而是缓存在内存中。

C.RedoLog保证事务的持久性。

D.UndoLog保证事务的原子性。

E.有一个隐含的特点,数据必须要晚于redolog写入持久存

时间: 2024-08-08 06:17:14

undolog redolog binlog的相关文章

MySQL binlog相关分析

1.redolog.binlog的简单分析 图解:redolog和binlog机制 2.开启binlog及关注点 3.关注binlog的相关参数 4.binlog模式分析 5.关于binlog的使用 补充:双一模式 一.区别redolog和binlog 1.如下表格的一个简单对比   redolog binlog 日志作用 保护脏数据 数据库备份恢复使用 引擎支持 只适合InnoDB引擎 所有引擎 日志格式 物理日志 逻辑日志,SQL语句 提交方式 快速提交 提交时一次性写入 保存形式 会被循环

MySQL · 引擎特性 · InnoDB 事务系统

MySQL · 引擎特性 · InnoDB 事务系统 前言 关系型数据库的事务机制因其有原子性,一致性等优秀特性深受开发者喜爱,类似的思想已经被应用到很多其他系统上,例如文件系统等.本文主要介绍InnoDB事务子系统,主要包括,事务的启动,事务的提交,事务的回滚,多版本控制,垃圾清理,回滚段以及相应的参数和监控方法.代码主要基于RDS 5.6,部分特性已经开源到AliSQL.事务系统是InnoDB最核心的中控系统,涉及的代码比较多,主要集中在trx目录,read目录以及row目录中的一部分,包括

Cassandra中的各种策略

1. 背景介绍 Cassandra 使用分布式哈希表(DHT)来确定存储某一个数据对象的节点.在 DHT 里面,负责存储的节点以及数据对象都被分配一个 token.token 只能在一定的范围内取值,比如说如果用 MD5 作为 token 的话,那么取值范围就是 [0, 2^128-1].存储节点以及对象根据 token 的大小排列成一个环,即最大的 token 后面紧跟着最小的 token,比如对 MD5 而言,token 2^128-1 的下一个 token 就是 0.Cassandra 使

MySQL中bin-log与redo-log的区别

首先,从体系结构上来讲: binlog由数据库上层(server 层)生成,是SQL执行的逻辑日志.redo log是存储引擎(innodb事务引擎)层面的物理格式的日志,记录的是对于每个页的修改. 作用上的区分: binlog用来进行数据恢复(基于时间点的) 和 主从复制. redolog用来保证事务的持久性,以及 crash recovery . 生成和结束的时间机制也不一样: InnoDB的redolog在事务进行中不断地被写入,而binlog在事务提交完成后进行一次写入 所以事务提交过程

MySQL(一)总体框架 & redo-log 和 bin-log 的介绍

文章部分总结来自课程,非原创 MySQL 组织架构     下面这张图就可以解释关于 MySQL 底层的组织架构了.     上面的图可以直观地展示两个重要的东西 : 一条 SQL 的执行流程 MySQL 的底层架构   大体来说,MySQL可以分为Server层和存储引擎层两部分. Server 层      Server层包括连接器.查询缓存.分析器.优化器.执行器等,涵盖MySQL的大多数核心服务功能,以及所有的内置函数(如日期.时间.数学和加密函数等),所有跨存储引擎的功能都在这一层实现

mysql如何保证redolog和binlog的一致性,安全性,效率。

和数据安转相关的参数 sync_binlog:控制binlog的刷新方式(写入到磁盘) innodb_flush_log_at_trx_commit:在innodb下控制着redo的写入方式 innodb_support_xa:外部事务,用来保证binlog和redo一致性的,俗称两段式提交 binlog_order_commits:按照binlog的写入顺序提交事务,保证redo和binlog的已执行 binlog_max_flush_queue_time: leader线程搜集binlog的

mysql日志redo log 和binlog

在上一篇中我们说到了mysql的基础架构,通常一个查询操作只会涉及到基础架构中的那几部分: 首先连接数据库,分析器进行语义.语法分析,优化器生成执行计划和索引选择.执行器执行对应的语句.存储引擎查看内存中是否有对应的数据,有的话直接返回,没有的话从磁盘查找(不考虑查询缓存):但是对于更新操作的话还需要用到日志来辅助 日志的作用:1.数据恢复需要用到binlog 2.数据库重启后需要redo log来保证数据的可靠,会出现数据还没写入磁盘服务器异常重启的情况 一.redo log(重做log) 由

MySQL binlog日志恢复数据

我们了解了MySQL 的 binlog 日志的开启方式以及 binlog 日志的一些原理和常用操作,我们知道,binlog 有两大作用,一个是使用 binlog 恢复数据,另一个就是用来做主从复制.本篇笔记就是来记录如何使用 binlog 日志来做数据恢复.当然了,使用 binlog 日志所恢复的数据只能是部分数据,并不能够使用 binlog 日志来做数据库的备份,如果想要做数据库备份,依然要使用我们传统的备份方法,而 binlog 可以作为增量备份. 视频链接:http://www.ronco

查看binlog文件的2种方式

1.使用show binlog events a.获取binlog文件列表 mysql> show binary logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000005 | 1288 | | mysql-bin.000006 | 120 | +------------------+-----------+ mysql>