1、binlog有几种模式？

Statement（基于SQL语句的复制）
Row（基于行的复制）
Mixed（混合模式）

2、MySQL怎么知道binlog是完整的 ?

一个事务的 binlog是有完整格式的。
1. statement 格式的 binlog，最后会有 COMMIT ；
2. row 格式的 binlog，最后会有一个 XID event。
3. 在 MySQL 5.6.2 版本以后，还引入了 binlog-checksum 参数，用来验证 binlog 内容的正确性

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

它们有一个共同的数据字段，叫XID。崩溃恢复的时候，会按顺序扫描redo log：
• 如果碰到既有 prepare 、又有 commit 的 redo log ，就直接提交；
• 如果碰到只有 parepare 、而没有 commit 的 redo log ，就拿着 XID 去 binlog 找对应的事务。判断 binlog 是否完整

4、为什么在正式的生产库上， binlog 都是开着的？

• redo log 是循环写，历史日志没法保留，起不到归档的作用；
• MySQL 系统依赖于 binlog，binlog 作为 MySQL 一开始就有的功能，被用在了很多地方。

5、binlog 有崩溃恢复的能力吗？

没有。

提示：MySQL 的原生引擎是MyISAM ，设计之初就有没有支持崩溃恢复。

6、为什么 redo log 要用两阶段提交？

redo log 和 binlog 是两个独立的逻辑，如果不用两阶段提交，要么就是先写完 redo log 再写binlog ，或者采用反过来的顺序，会产生日志与数据不一致的问题。

7、什么是两阶段提交？

redo log 的事务提交被分为 prepare 和 commit。

提示：事务在提交的时候才会到两阶段，在执行的时候只会增加日志记录而不会提交。

8、redo log 和 binlog 谁先提交事务？

时序上 redo log 先 prepare ， 再写 binlog ，最后再把 redo log commit。
具体而言，崩溃恢复在两阶段提交不同时刻的判断规则如下：
1. 如果 redo log 里面的事务是完整的，也就是已经有了 commit 标识，则直接提交；
2. 如果 redo log 里面的事务只有完整的 prepare ，则判断对应的事务 binlog 是否存在并完整（通过xid来联系起来），
a. 如果 binlog 完整，则提交事务；（崩溃恢复通过 redo log prepare + binlog恢复）
b. 否则，回滚事务。

9、redo log 有哪三种状态？

1. 存在 redo log buffer 中，物理上是在 MySQL 进程内存中；
2. 写到磁盘 (write) ，但是没有持久化（ fsync) ，物理上是在文件系统的 page cache 里面；
3. 持久化到磁盘，对应的是 hard disk。

10、为什么一般设置在 redo log 事务提交的 prepare 阶段将日志持久化到磁盘？