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 阶段将日志持久化到磁盘？
因为有一个崩溃恢复的判断逻辑是要依赖于 prepare 的 redo log ，再加上 binlog 来恢复的，所以经常在 prepare 阶段就把它持久化。
全部评论
(0) 回帖