这是我参与「第三届青训营 -后端场」笔记创作活动的的第9篇笔记
binlog是属于MySQL Server层面的，又称为归档日志，属于逻辑日志，是以二进制的形式记录的是这个语句的原始逻辑，依靠binlog是没有CrashSafe能力的
逻辑日志：可以简单理解为记录的就是sql语句。
binlog主要使用场景：主从复制，数据恢复
主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
数据库恢复方法
系统会定期整库备份，binlog会记录所有的逻辑操作，当需要恢复到指定的某一时刻时：
- 首先，找到最近的一次全量备份
- 然后，从备份时间开始，将binlog依次取出来，一直重放到指定的时刻
为什么 redo log 具有 crash-safe 的能力，而 binlog 没有？
**CrashSafe**指MySQL服务器宕机重启后，能够保证：
- 所有已经提交的事务的数据仍然存在。
- 所有没有提交的事务的数据自动回滚。
当数据库 crash(崩溃) 后，想要恢复未刷盘但已经写入 redo log 和 binlog 的数据到内存时，binlog 是无法恢复的。虽然 binlog 拥有全量的日志，但没有一个标志让 innoDB 判断哪些数据已经刷盘，哪些数据还没有。
但 redo log 不一样，只要刷入磁盘的数据，都会从 redo log 中抹掉，数据库重启后，直接把 redo log 中的数据都恢复至内存就可以了。这就是为什么 redo log 具有crash-safe的能力，而binlog 不具备。
redo log 和 binlog的区别：
- redo log是InnoDB特有的日志，binlog 所有引擎都可以使用
- redo log是物理日志，记录的是该数据页更新的内容；
binlog是逻辑日志，记录的是这个更新语句的原始逻辑 - redo log是循环写的，空间固定会用完。binlog是可以追加写的，当binlog写到一定大小会切换到下一个，并不会覆盖以前的日志
- binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。
update语句执行流程
首先进行sql查询语句的执行流程，如需 update ID = 2 ，先找到这一行，执行以下流程：
为什么update语句 要有两阶段提交？
这是为了让两份日志之间的逻辑一致。
当执行update语句时，数据修改完更新到内存，先写redo log 并设置redo log为准备阶段，再写binlog，写完binlog设置为redo log为结束阶段。两个中间有一个写入差错，那么该操作都是失败，即redo log发现只有准备阶段没有结束，那么会将该条事务进行回滚。
假如不采用两阶段提交机制的话那么会有什么影响呢？
（1）先写redo log：当写完redo log设备断电，binlog没有记录，那么数据库刚刚启动之后通过redo log可以恢复到断电前的状态，但是由于binlog没有写入，当从某个节点进行恢复时(或者创建一个备份库)，那么binlog没用这条记录，恢复出来的数据库是有错误的。
（2）先写binlog：当写完binlog设备断电，redo log没有记录，还没有写入磁盘，那么数据库重新启动之后通过redo log恢复并没有这条数据，而当从某个时间点进行恢复(或者创建一个备份库)时，binlog有相关数据，所以会导致数据不统一。
