1. Binlog****
Binlog是一种逻辑日志——例如Binlog的statement格式记录原始SQL语句，且一个事务的日志在Binlog中是连续排列的
而Binlog是MySQL层面的东西，用于实现主从复制，与使用的存储引擎无关。
只有提交成功的事务才写入Binlog日志
(1) 一个事务的提交既要写Binlog日志又要写Redo Log日志，如何保证双写的原子性****
通过类似于checksum的办法或者Binlog中的结束标记来判断出某个事务的Binlog这是不是不完整的Binlog，从而把不完整的部分截掉
由于双写Binlog和Redo Log发生在同一台机器上，这其实是一个内部分布式事务，可以使用两阶段提交法来实现双写的原子性。简单来说就是：
1）第一阶段（准备阶段）：MySQL Server要求innoDB完成将事务内容写入Redo Log中的工作，只等事务提交；以及，MySQL Server完成Binlog内容写入内存的工作，只等刷盘。两个都准备好之后，会向MySQL Server发送OK反馈，紧接着执行第二阶段。【等事务提交，等刷盘】
2）第二阶段（提交阶段）：收到客户端的Commit指令，MySQL Server先将内存中的Binlog刷盘，然后让innoDB执行事务的提交。两个都完成之后，会向MySQL Server发送OK反馈，两阶段提交结束。【先刷盘，再提交事务】
(2) 若双写Binlog和Redo Log的过程中发生宕机，处理思路为：****
1）若宕机发生在第一阶段，此时Binlog还在内存中，宕机导致全部消失。而Redo Log记录了未提交的日志，MySQL Server重启后感知到Binlog中不存在Redo Log中记录的未提交事务，会自行回滚未提交事务的Redo Log日志；【回滚Redo Log】
2）若宕机发生在第二阶段，Binlog写了一半，innoDB还未执行提交，MySQL Server重启后会对Binlog做截断，对Redo Log中记录的未提交事务做回滚；【Binlog截断，回滚Redo Log】
3）若宕机发生在第二阶段，Binlog写入成功，innoDB还未执行提交，MySQL Server重启后会通过checksum的办法或者Binlog中的结束标记感知到Binlog写入成功，紧接着对Binlog中存在的、但Redo Log未提交的事务发起提交。【Redo Log提交】
总的来说，如果 Binlog 没有写完， 回滚Redo Log， 否则 提交Redo Log****
2. MySQL主从复制模式****
在MySQL的Master / Slave集群模式中，有三种主从复制模式：
1）同步复制：所有的Slave都收到Master发送的Binlog，并且接收完，Master才认为事务提交成功，再对客户端返回成功。这种方式最安全，但是性能很差；
2）异步复制：只要Master事务提交成功，就对客户端返回成功。后台线程异步地将Binlog发送给Slave，然后Slave回放Binlog。这种方式性能最好，但是可能会导致数据丢失；
3）半同步复制：Master事务提交后，同时把Binlog同步给Slave，只要有部分（数量可以配置）Slave收到了Binlog，就认为事务提交成功，对客户端返回。
对于半异步复制，如果Slave超时后还未返回，也会退化为异步复制。所以无论是异步复制还是半异步复制，都无法严格保证主从中的数据完全一致，主从复制的延迟会导致主节点宕机后部分数据未来得及同步到从节点，从而丢失数据。但是主节点宕机后，还是要立即切换到从节点，保证服务的可用（牺牲一致性保证可用性），数据的丢失可以通过后续的人工干预来补偿。
