日志类型
-
redolog
-
undolog
-
binlog
-
errorlog
-
slow query log
-
general log
-
relaylog
谈谈redolog 、 undolog 和 binlog的异同
1. 实现层级
binlog是mysql服务层实现的
redolog和undolog是引擎层实现的, 只存在于innodb中,myisam引擎并没有实现, 统称为事务日志
2. 用途
-
redo log
确保事务的持久性如果发生故障时(如: 系统宕机, 电源异常等),尚有数据未写入磁盘,在重启mysql服务的时候,根据redo log进行重做,从而达保证事务的持久性。
-
undo log
- 用于回滚
- MVCC
首先明确undo log绝对不是redo log的逆过程。它可以保存事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制(MVCC)下的读。
-
binlog
- 复制:MySQL Replication在Master端开启binlog,Master把它的二进制日志传递给slaves并回放来达到master-slave数据一致的目的
- 数据恢复:通过mysqlbinlog工具恢复数据
- 增量备份
3.存储内容、格式
-
redo log
物理日志记录的是物理数据页面的修改的信息(数据库中每个页的修改),面向的是表空间、数据文件、数据页、偏移量等。
-
undo log
逻辑日志
在执行undo的时候,仅仅是将数据从逻辑上恢复至事务之前的状态,而不是从物理页面上操作实现的,与redo log不同。 -
binlog
逻辑日志记录的是对数据存在变更的sql语句。
binlog只会保存对数据存在更改的记录,像select/show这类查询类的语句是不记录的。
4. 生命周期
-
redolog
事务开始之后,就开始产生 redo log 日志了,在发出事务提交指令时,先保证缓存中的redo log写入完毕,才执行提交动作。
当对应事务的数据写入完成(持久化完成)之后,redo log的使命也就完成了,日志占用的空间就可以重用(redo log的日志文件是循环写入的)。 -
undolog
事务开始之前,将当前事务版本生成 undo log,undo log 也会产生 redo log 来保证 undo log 的可靠性。
当事务提交之后,undo log 并不能立马被删除,而是放入待清理的链表,
由 purge 线程判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息,从而决定是否可以清理 undo log 的日志空间。 -
binlog
事务提交的时候,一次性将事务中的 所有sql 语句按照一定的格式记录到 binlog 中,这里与 redo log 很明显的差异就是 redo log 并不一定是在事务提交的时候才刷新到磁盘,而是在事务开始之后就开始逐步写入磁盘。binlog 的默认保存时间是由参数 expire_logs_days 配置的,对于非活动的日志文件,在生成时间超过 expire_logs_days 配置的天数之后,会被自动删除。
两阶段提交
redolog和binlog都写入了之后再提交数据,确保日志数据都正常了才写入磁盘。
redolog 保证的是数据库的 crash-safe 能力。采用的策略就是常说的“两阶段提交”。
一条update的SQL语句是按照这样的流程来执行的:
将数据页加载到内存 → 修改数据 → 更新数据 → 写redolog(状态为prepare) → 写binlog → 提交事务(数据写入成功后将redo log状态改为commit)