MySQL---两阶段提交

在MySQL中，所谓的两阶段提交就是redo log和binlog 两个阶段的commit过程。

在两阶段提交的不同时刻，MySQL 异常重启会出现什么现象？

       1、在时刻 A 发生宕机，也就是写入 redo log 处于 prepare 阶段之后、写 binlog 之前，发生了崩溃（crash），由于此时 binlog 还没写，redo log 也还没提交，所以崩溃恢复的时候，这个事务会回滚。这时候，binlog 还没写，所以也不会传到备库。

       2、在时刻 B发生宕机，也就是 binlog 写完，redo log 还没 commit 前发生 crash，那崩溃恢复的时候 MySQL 会怎么处理？

           如果 redo log 里面的事务是完整的，也就是已经有了 commit 标识，则直接提交；

          如果 redo log 里面的事务只有完整的 prepare，则判断对应的事务 binlog 是否存在并完整：

                a.  如果是，则提交事务；

                b.  否则，回滚事务。

如何判断binlog是完整的？

一个事务的 binlog 是有完整格式的：

       statement 格式的 binlog，最后会有 COMMIT；

       row 格式的 binlog，最后会有一个 XID event。

       MySQL 5.6.2 版本以后，还引入了 binlog-checksum 参数，用来验证 binlog 内容的正确性。

redo log 和 binlog 是怎么关联起来的?

       它们有一个共同的数据字段，叫 XID。

       崩溃恢复的时候，会按顺序扫描 redo log：如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；

       如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。

redo log常用的大小：

推荐直接将 redo log 设置为 4 个文件、每个文件 1GB 吧。

 

redo log 并没有记录数据页的完整数据，所以它并没有能力自己去更新磁盘数据页，也就不存在“数据最终落盘，是由 redo log 更新过去”的情况。

如果是正常运行的实例的话，数据页被修改以后，跟磁盘的数据页不一致，称为脏页。最终数据落盘，就是把内存中的数据页写盘。这个过程，甚至与 redo log 毫无关系。

在崩溃恢复场景中，InnoDB 如果判断到一个数据页可能在崩溃恢复的时候丢失了更新，就会将它读到内存，然后让 redo log 更新内存内容。更新完成后，内存页变成脏页，就回到了第一种情况的状态。

 

redo log buffer 就是一块内存，用来先存 redo 日志的。也就是说，在执行第一个 insert 的时候，数据的内存被修改了，redo log buffer 也写入了日志。

真正把日志写到 redo log 文件（文件名是 ib_logfile+ 数字），是在执行 commit 语句的时候做的。~~~~这个做法类似于unbuffered database的做法。

binlog的缺陷：

binlog 没有能力恢复“数据页”。我理解binlog只能实现逻辑上的重做。

InnoDB 引擎使用的是 WAL 技术，执行事务的时候，写完内存和日志，事务就算完成了。如果之后崩溃，要依赖于日志来恢复数据页。

binlog的实际应用场景：

在正式的生产库上，binlog 都是开着的。因为 binlog 有着 redo log 无法替代的功能。

一个是归档。redo log 是循环写，写到末尾是要回到开头继续写的。这样历史日志没法保留，redo log 也就起不到归档的作用。~~~~换言之，mysql redo log的归档功能其实是没有的，和其他主流的商业数据库是不一样的。

一个就是 MySQL 系统依赖于 binlog。binlog 作为 MySQL 一开始就有的功能，被用在了很多地方。其中，MySQL 系统高可用的基础，就是 binlog 复制。~~~也是因为redo log无法归档，也没有办法被及时的应用到其他数据库上，所以只能靠binlog去实现逻辑上的重做来保证主备一致。