redo log和binlog

redo log与WAL技术

• redo log的WAL技术可以与孔乙己赊账的粉板类似。当店里生意较忙的时候，有人要赊账了，先在粉板上记录某某赊账多少钱，等到晚上再翻阅赊账本，将粉板的记录汇总到账本上。或者当粉板满了之后，掌柜需要停下手里的活，将粉板记录腾进账本中。
• WAL（write ahead logging）技术也是如此，当数据库表更新时，先写日志，再写磁盘。因为写入磁盘需要遍历物理页选择合适位置插入（数据页的物理结构是B+树，因此要遍历B+树），而读写磁盘的代价较高。而且使用redo log可以实现cash-safe，也就是数据库异常重启的时候，在内存中的更新会丢失，但是更新之后保存在redo log，因此不会丢失更新.

redo log结构

image.png

• redo log是固定大小的。如图所示，redo log有两个指针，write pos和check point。其中write pos是写入的下标，check point是当前要擦除的位置，write pos和check point之间是可以写入的空间。如果write pos追上check point，说明redo log满了，这时候就先不能更新记录，而是停下来擦除redo log
• redo log可以保证即使Mysql异常重启了，数据也不会丢失。这个能力称为cash-safe

binlog

binlog与redo log不同，它是用于Server引擎的，用于日志归档的。它是追加日志，不用担心会写满。它会记录更新的逻辑操作，当不小心误删数据库时,可以取最近的一次全量备份，从这个备份恢复到临时库。然后，从备份的时间点开始，将备份的binlog依次取出来，重放到误删的时间点。

binlog和redo log区别

1. redo log是引擎层特有的，binlog是Server层的，所有引擎都可用。
2. redo log是物理日志，记录某个数据页的更改。binlog是逻辑日志，记录更新的逻辑。binlog有两种模式，一种是statement格式记录sql语句，一种是row格式，记录行的内容。
3. redo log是循环写，空间会用完。binlog是追加写，写满会切换下一个。

更新流程

image.png

1. 执行器先找引擎，引擎搜索B+树找到ID为2的行，如果在内存中，那么返回行数据，否则要先读入到内存中
2. 执行器拿到行数据，将原来值加一，得到新的一行，再调用引擎写入新数据行。
3. 引擎将辛淑君更新到内存，并将记录记到redo log。此时redo log处于prepare状态，通知执行器。
4. 执行器生成binlog，把binlog写入磁盘
5. 执行器调用引擎提交事务接口，将写入的redo log改成commit。

两阶段提交

两阶段提交可以保证数据的一致性，cash-safe和数据库恢复

• 比如说在redo log写入之后，数据库异常重启，由于redo log没有commit，因此事务会回滚。以后用binlog恢复的数据库和原来就是一致的。保持了一致性。
• 如果在redo log写入之后，处于prepare阶段，然后写binlog，这时候数据库异常重启，之后数据库会检查binlog是否写入完整，如果完整的话就可以commit，否则要进行回滚。
• 由此可见，两阶段提交，可以保证事务的cash-safe和备份

参数设置

• innodb_flush_log_at_trx_commit设置为1，表示事务的redo log会持久化到磁盘中。保证Mysql重启数据不丢失。
• sync_binlog也设置为1，表示事务的binlog都持久化到磁盘中，这样Mysql重启，更新不会丢失。