MySQL基础----理解redolog和binlog的作用
SQL 语句分类:
-
Data Definition Language (DDL数据定义语言) 如:建库,建表(create / alter / drop)
-
Data Manipulation Language(DML数据操纵语言),如:对表中的记录操作增删改(insert /update/delete)
-
Data Query Language(DQL 数据查询语言),如:对表中的查询操作(select /show)
-
Data Control Language(DCL 数据控制语言),如:对用户权限的设置(grant /revoke)
只要我们写的是DML语句(insert,update,delete,create)等等,那么我们在数据库服务端执行的时候就会涉及到 redo log(重做日志) 和 binlog(归档日志) 两个日志文件的变动。
两个日志的主要区别:
- redo log 是物理日志,记录的是“在某个数据页上做了什么修改”;binlog 是逻辑日志,记录的是这个语句的原始逻辑,比如“给 ID=2 这一行的 c 字段加 1 ”。
- redo log 是循环写的,空间固定会用完;binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。
- redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。
关于redolog和binlog详细内容见:
https://time.geekbang.org/column/article/68633
关于update操作的内部流程:
- 执行器先找引擎取 ID=2 这一行。ID 是主键,引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中,就直接返回给执行器;否则,需要先从磁盘读入内存,然后再返回。
- 执行器拿到引擎给的行数据,把这个值加上 1,比如原来是 N,现在就是 N+1,得到新的一行数据,再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中,同时将这个更新操作记录到 redo log 里面,此时 redo log 处于 prepare 状态。然后告知执行器执行完成了,随时可以提交事务。
- 执行器生成这个操作的 binlog,并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口,引擎把刚刚写入的 redo log 改成提交(commit)状态,更新完成。
两阶段提交
将 redo log 的写入拆成了两个步骤:prepare 和 commit,这就是"两阶段提交"。这是为了让两份日志之间的逻辑一致。
可以认为,redo是物理的,binlog是逻辑的;现在由于redo是属于InnoDB引擎,所以必须要有binlog,因为你可以使用别的引擎。
保证数据库的一致性,必须要保证2份日志一致,使用的2阶段式提交;其实感觉像事务,不是成功就是失败,不能让中间环节出现,也就是一个成功,一个失败。
Bin log 用于记录了完整的逻辑记录,所有的逻辑记录在 bin log 里都能找到,所以在备份恢复时,是以 bin log 为基础,通过其记录的完整逻辑操作,备份出一个和原库完整的数据。
如果不是两阶段提交,而是各自先后完成:
若 redo log 写入成功,bin log 写入失败,则后续通过 bin log 恢复时,恢复的数据将会缺失一部分。(如 redo log 执行了 update t set status = 1,此时原库的数据 status 已更新为 1,而 bin log 写入失败,没有记录这一操作,后续备份恢复时,其 status = 0,导致数据不一致)。
若是两阶段提交,这时候redolog只是完成了prepare, 而binlog又失败,那么事务本身会回滚,这个库里面status的值也会是0。
若先写入 bin log,当 bin log 写入成功,而 redo log 写入失败时,原库中的 status 仍然是 0 ,但是当通过 bin log 恢复时,其记录的操作是 set status = 1,也会导致数据不一致。