我们还是从一个表的一条更新语句说起,下面是这个表的创建语句,这个表有一个主键 ID 和一个整型字段 c:
mysql> create table T(ID int primary key, c int);
如果要将 ID=2 这一行的值加 1,SQL 语句就会这么写:
mysql> update T set c=c+1 where ID=2;
在一个表上有更新的时候,跟这个表有关的查询缓存会失效,所以这条语句就会把表 T 上所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因
查询流程不一样的是,更新流程还涉及两个重要的日志模块: redo log(重做日志)和 binlog(归档日志)
InnoDB 的 redo log 是固定大小的,比如可以配置为一组 4 个文件,每个文件的大小是 1GB,那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写,写到末尾就又回到开头循环写,如下面这个图所示
有了 redo log,InnoDB 就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为crash-safe
redo log是innodb自己的, binlog是mysql的server层的.
所以说. 为什么会有两份日志呢?
这两种日志有以下三点不同
我们再来看一下执行update的流程
回到最开始的问题: 怎样让数据库恢复到半个月内任意一秒的状态?
binlog 会记录所有的逻辑操作,并且是采用“追加写”的形式。如果你的 DBA 承诺说半个月内可以恢复,那么备份系统中一定会保存最近半个月的所有 binlog,同时系统会定期做整库备份。这里的“定期”取决于系统的重要性,可以是一天一备,也可以是一周一备
当需要恢复到指定的某一秒时,比如某天下午两点发现中午十二点有一次误删表,需要找回数据,那你可以这么做:
用反证法证明为什么需要两阶段提交
由于 redo log 和 binlog 是两个独立的逻辑,如果不用两阶段提交,要么就是先写完 redo log 再写 binlog,或者采用反过来的顺序。我们看看这两种方式会有什么问题:
仍然用前面的 update 语句来做例子。假设当前 ID=2 的行,字段 c 的值是 0,再假设执行 update 语句过程中在写完第一个日志后,第二个日志还没有写完期间发生了 crash,会出现什么情况呢?
redo log 和 binlog 都可以用于表示事务的提交状态,而两阶段提交就是让这两个状态保持逻辑上的一致
redo log 用于保证 crash-safe 能力, innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到磁盘
sync_binlog 这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘
两阶段提交是跨系统维持数据逻辑一致性时常用的一个方案
1prepare阶段 2写binlog 3commit
binlog 和 redolog 有一个共同字段叫XID。崩溃恢复的时候,会按照顺序扫描redo log:
1.如果碰到既有prepare、又有commit的redo log,就直接提交
2.如果碰到只有prepare、而没有commit的redo log,就拿着XID去binlog找对应的事务
redolog binlog undolog的区别详细解析:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。