【MYSQL】四：让你全新认识bin log 与 redo log

• redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

• redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。

binlog_format——binlog是可以调整格式的
row ：基于行，记录哪条数据被修改了，修改成什么样了，大量日志
statment：基于SQL，某些函数影响主从备一致
mixed：以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。

• redo log是循环写的，空间固定会用完 writepoint 是当前记录位置，往后移，checkpoint是要刷盘的位置，白色部分就是空留位置
  
  binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

write：表示由内存写入缓存
flush：由缓存写入日志磁盘

• sync_binlog：控制写入缓存与binlog
• innodb_flush_log_at_trx_commit：控制写入缓存与redo

0： 每隔1s (written +flushed )
1：事务完成就 ( write +flush )
2：事务完成written + OS来flushed

1. 写入redolog，处于perpare状态
2. 写入binlog
3. 提交事务，处于commit状态

如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。redo log和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

redo log会记录刷到数据库的日志，系统crash我们完全可以依靠redo log进行恢复。

bin log记录的是全量的日志，没有记录哪个已经刷盘哪个没有刷盘，所以不能依靠redo log恢复

• 归档，复制，数据分析等都离不开binlog

• binlog是MySQL的server本身开始就有的，而redo log是InnoDB在作为MySQL的插件加入MySQL引擎家族之前，就已经是一个提供了崩溃恢复和事务支持的引擎了

• 使用binlog恢复到某个时间段的数据。比如某天下午两点发现中午十二点有一次误删表，需要找回数据，那你可以这么做：首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上的一个备份，从这个备份恢复到临时库；然后，从备份的时间点开始，将备份的binlog依次取出来，重放到中午误删表之前的那个时

• 使用binlog扩容:当你需要扩容的时候，也就是需要再多搭建一些备库来增加系统的读能力的时候，现在常见的做法也是用全量备份加上应用binlog来实现的；

• 主从复制：把binlog给从主库复制过来进行恢复，保证一致性