1.mysql日志
物理日志
redo恢复 持久性
undo 回滚 原子性
WAL机制 (Write Ahead Log)
逻辑日志
binlog

二阶段提交保持一致性
1.Storage Engine（InnoDB） transaction prepare阶段：存储引擎的准备阶段,写redo-buffer

此时SQL已经成功执行，并生成xid信息及redo和undo的内存日志。

2.Binary log日志提交：写binlog并落盘.

write()将binary log内存日志数据写入文件系统缓存。

fsync()将binary log文件系统缓存日志数据永久写入磁盘。

3.Storage Engine（InnoDB）内部提交：落盘redo日志.

修改内存中事务对应的信息，并且将日志写入重做日志缓冲。

调用fsync将确保日志都从重做日志缓冲写入磁盘。

一旦步骤2中的操作完成，就确保了事务的提交，即使在执行步骤3时数据库发送了宕机。

即binlog落盘成功,就算redo未落盘成功,那么事务也算是提交成功了.

binlog落盘条件：参数sync_binlog： 0每秒落盘，1每次commit落盘 n 每n个事物落盘

此外需要注意的是，每个步骤都需要进行一次fsync操作才能保证上下两层数据的一致性。步骤2的fsync参数由sync_binlog控制，步骤2的fsync由参数innodb_flush_log_at_trx_commit控制。(双1配置)

两阶段提交:先写redo -buffer再写binlog 并落盘最后落盘redo-buffer.

最终:mysql在落盘日志的时候,先落盘binlog,再落盘redo.

引入二阶段提交 使得binlog又成为了性能瓶颈，先前的Redo log 组提交 也成了摆设。为了再次缓解这一问题，MySQL增加了binlog的组提交，目的同样是将binlog的多个刷盘操作合并成一个，结合Redo log本身已经实现的 组提交，分为三个阶段(Flush 阶段、Sync 阶段、Commit 阶段)完成binlog 组提交，最大化每次刷盘的收益，弱化磁盘瓶颈，提高性能。

三阶段提交（组提交）
1.参数设置
sync_binlog=1
innodb_flush_log_at_trx_commit=1
3.Flush 阶段

首先获取队列中的事务组

将Redo log中prepare阶段的数据刷盘

将binlog数据写入文件，当然此时只是写入文件系统的缓冲，并不能保证数据库崩溃时binlog不丢失

Flush阶段队列的作用是提供了Redo log的组提交

如果在这一步完成后数据库崩溃，由于协调者binlog中不保证有该组事务的记录，所以MySQL可能会在重启后回滚该组事务

Sync 阶段

这里为了增加一组事务中的事务数量，提高刷盘收益，MySQL使用两个参数控制获取队列事务组的时机：

    binlog_group_commit_sync_delay=N：在等待N μs后，开始事务刷盘(图中Sync binlog)

    binlog_group_commit_sync_no_delay_count=N：如果队列中的事务数达到N个，就忽视binlog_group_commit_sync_delay的设置，直接开始刷盘

Sync阶段队列的作用是支持binlog的组提交

如果在这一步完成后数据库崩溃，由于协调者binlog中已经有了事务记录，MySQL会在重启后通过Flush 阶段中Redo log刷盘的数据继续进行事务的提交

Commit 阶段

首先获取队列中的事务组

依次将Redo log中已经prepare的事务在引擎层提交

Commit阶段不用刷盘，如上所述，Flush阶段中的Redo log刷盘已经足够保证数据库崩溃时的数据安全了

Commit阶段队列的作用是承接Sync阶段的事务，完成最后的引擎提交，使得Sync可以尽早的处理下一组事务，最大化组提交的效率