有binlog的CR方式（重點核心！！）：
有binlog情況下，commit動作開始時，會有一個Redo XID 的動作記錄寫到redo，然后寫data到binlog，binlog寫成功后，會將binlog的filename，日志寫的位置position再寫到redo(position也會寫到pos文件里)，此時才表示該事務完成（committed）。如果只有XID，沒有后面的filename和position，則表示事務為prepare狀態。
流程：
commit; --> write XID to redo. --> write data to Binlog. --> write filename,postsion of binlog to redo. --> commited.
記錄Binlog是在InnoDB引擎Prepare（即Redo Log寫入磁盤）之后，這點至關重要。
如果事務在不同階段崩潰,recovery時會發——
| crash發生階段 | 事務狀態 | 事務結果 |
| 當事務在prepare階段crash | 該事務未寫入Binary log，引擎層也未寫redo到磁盤。 | 該事務rollback。 |
| 當事務在binlog寫階段crash | 此時引擎層redo已經寫盤，但Binlog日志還沒有成功寫入到磁盤中。 | 該事務rollback。 |
| 當事務在binlog日志寫磁盤后crash，但是引擎層沒有來得及commit | 此時引擎層redo已經寫盤，server層binlog已經寫盤，但redo中事務狀態未正確結束。 |
讀出binlog中的xid，並通知引擎層提交這些XID的事務。引擎提交這些后，會回滾其他的事務，使引擎層redo和binlog日志在事務上始終保持一致。 事務通過recovery自動完成提交。 |
總結起來說就是如果一個事務在prepare階段中落盤成功，並在MySQL Server層中的binlog也寫入成功，那這個事務必定commit成功。
（redolog 寫成功 && binlog 寫成功 == commit，缺一不可。）