MySQL实战第二课
日志系统：redolog和binlog
评论1：
1. 如果是主从模式下，binlog是必须的，因为从库的数据同步依赖的就是binlog；
2. 如果是单机模式，并且不考虑数据库基于时间点的还原，binlog就不是必须，因为有redo log就可以保证crash-safe能力了；但如果万一需要回滚到某个时间点的状态，这时候就无能为力，所以建议binlog还是一直开启；
评论2：
1.单独依靠redologo无法做到指定某一点的恢复，是不是因为redologo是循环写的，如果要恢复的那一时刻被擦掉了，就无法知道这点的数据变动轨迹，而binlog是追加的方式，在文件完整的前提下，数据的变动轨迹都可以知晓
2. 最后三步是 ①引擎写redolog，并处于prepare状态 ②执行器写binlog，成功后，发送commit
③引擎刚写入的redolog改变为commit状态
如果crash发生后 redolog =prepare binlog没有对应写入记录，则回滚
如果crash发生后 redolog =prepare binlog有对应写入记录，则提交
感觉有点像 1 && 1= 1 1&&0=0 0&&1=0
3.binlog模式 ①记录sql语句 ②记录更新前后的行 一般是用哪种模式 row模式
评论3：
刚开始我也是比较疑惑既然有了binlog，为何还需要redolog。把老师的文章反复看了几遍大概弄明白了，redolog是innodb引擎特有的，为了WAL而存在,更新操作是先写入redolog，之后异步写到数据的磁盘文件中。假设现在前后更新了2条记录并且都写入binlog后突然宕机，在服务重启后，如果只根据binlog是无法获知当前磁盘上的数据文件中那2条记录的状态是否是最新的（除非从头开始跑一遍binlog），所以一定要借助redolog才能知道宕机前有哪些记录还没更新到磁盘。如果存储引擎不支持WAL，也不支持事务回滚，每次更新都是直接更新到数据磁盘中，这应该不需要考虑宕机的问题。因为WAL的异步写入存在，所以需要解决宕机的恢复问题，需要redolog的协助，而redolog需要和binlog保持状态一致，这又要依靠两阶段提交。
