}
在任何情况下（机器掉电）mysqld crash或者os crash，MySQL仍然能保证数据库的一致性。数据的一致性是如何做到的哪？正是二阶段提交。
我们结合几种场景来分析下二阶段提交是如何做到的：
1.prepare阶段，redo log落盘前，mysqld crash
2.prepare阶段，redo log落盘后，binlog落盘前，mysqld crash
3.commit阶段，binlog落盘后，mysqld crash
对于第一种情况，由于redo没有落盘，毫无疑问，事务的更新肯定没有写入磁盘，数据库的一致性受影响；
对于第二种情况，这时候redo log写入完成，但binlog还未写入，事务处于TRX_STATE_PREPARED状态，这是提交还是回滚呢？
对于第三种情况，此时，redo log和binlog都已经落盘，只是undo状态没有更新，虽然redo log和binlog已经一致了，事务是否应该提交？
我们结合mysqld异常重启后的执行逻辑以及关键的源代码。
对于第三种情况，我们可以搜集到未提交事务的binlog event，所以需要提交；
对于第二种情况，由于binlog未写入，需要通过执行回滚操作来保证数据库的一致性。
异常重启后，如何判断事务该提交还是回滚
1.读binlog日志，获取崩溃时没有提交的event； //info->commit_list中含有该元素
2.若存在，则对应的事务要提交；否则需要回滚。
判断事务提交或回滚源码如下：
上面讨论了两阶段提交的基本流程，以及服务器异常crash后，mysql如何重启恢复保证binlog和数据的一致性。
简而言之，对于异常的xa事务，若binlog已落盘，则事务应该提交；binlog未落盘，则事务就应该回滚。
//异常重启后，回滚流程
innobase_rollback_by_xid
rollback_by_xid
trx_rollback_resurrected
trx_rollback_active
row_undo
{ //从回滚页获取undo记录 //分析undo记录类型 if (insert)
row_undo_ins else row_undo_mod
}
//异常重启后，提交流程
commit_by_xid
trx_commit_for_mysql
//写binlog接口
handler.cc:binlog_log_row
sql/binlog.cc:commit
mysys/my_sync:my_sync
sql/binlog.cc:sync_binlog_file
handler/ha_innodb.cc:innobase_xa_prepare
binlog日志文件是为了解决MySQL主从复制功能而引入的���份新日志文件，它包含了引发数据变更的事件日志集合。
从库请求主库发送 binlog 并通过日志事件还原数据写入从库，所以从库的数据来源为 binlog。
这样 MySQL 主库只需做到 binlog 与本地数据一致就可以保证主从库数据一致（暂且忽略网络传输引发的主从不一致）。