redo log 与 bin log 以及两阶段提交

两者区别？

1.  适用对象不同
   1. redo log 是innodb存储引擎实现的日志
   2. binlog 是server层实现的日志，所有存储引擎都可以使用
2. 文件格式不同
   1. binlog 支持三种文件格式   分别是 statement（默认） ，row ，mixed
      1. statement ： 每一条修改数据的sql都会记录到binlog日志中，但会出现动态函数的问题，比如uuid  或者now 等函数， 在主从复制之后得到的结过并不相同。
      2. row： 记录行数据具体被修改为什么样子，不会存在动态函数问题，但是每一条修改行都需要记录，比如更新，更新多少行就要记录多少，使binlog文件大。
      3. mixed：包含statement 和 row 它会根据情况自动使用row 还是statement
   2. redo log 是物理日志，记录了脏页数据做了什么修改
3. 写入方式不同
   1. binlodg是追加写，写满一个文件又写下一个
   2. redo log 是循环写，日志大小是固定的，保存未被刷入磁盘的数据
4. 用途不同
   1. binlog 用于主从复制，备份恢复
   2. redo log 用于掉电恢复，等故障恢复

两阶段提交

引入： 对于mysql集群场景，redo log 主要保证主库的数据，从库的数据来自binlog ，如果redo log 与binlog 的数据不一致，那就会导致主从数据不一致，

        1. 在redo log 刷盘成功后，mysql宕机，而binlog还灭有来的及写入，当重启后，会根据redo log 恢复，而binlog 里并没有对应记录，这时，从库的数据就会和主库不一致。

        2. 在binlog 刷盘成功后，mysql宕机，但redo log 还没有刷盘，这时，恢复后redo log没有对应的值，也会导致，主库与从库的数据不一致

其实也就是要保证两者同时成功，同时失败

两阶段提交分为 ：

• prepare阶段  
  • （开启内部XA事务）先进行redo log 的提交，然后将事务状态设置为prepare，然后将redolog 进行持久化
• commit阶段   然后将binlog进行持久化，然后将redo log对应事务的状态设置为commit，之后就认为都执行成功

当遇到宕机时，如果redo log 为prepare状态，然后binlog没有刷盘成功时宕机，就将redo log 回滚即可， 在redo log 和 bin log 都刷盘后，就直接提交事务即可（根据redo log 的XA事务id去binlog查看是否存在对应id的binlog来判断）

两阶段提交的缺点

• 磁盘i/o次数高    每次事务提交都要保证redo log 与binlog 都刷盘成功，要调用两次fsync操作磁盘 性能不佳
• 锁竞争激烈     两阶段提交能够保证单个事务执行情况下两个日志内容一致，但在多事务情况下，不能保证两者的提交顺序一致，因此需要通过加锁来保证原子性