MySQL兩階段交易認可

標籤：

參數介紹

innodb_flush_log_at_trx_commit

0: 每隔1s，系統後台線程刷log buffer,也就是把redo日誌刷盤，這裡會調用fsync，所以可能丟失最後1s的事務。

1: 每次commit時，刷redo日誌，確定fsync刷盤

2: 每次提交時，刷redo日誌到檔案系統，不調用fsync刷盤，5.6.6之前是每隔1s刷盤，之後的版本是通過參數innodb_flush_log_at_timeout設定，預設也是1s。所以也可能丟最後一秒的事務。如果有掉電保護群組件的話，可以開啟。

sync_binlog

表示每多少個sync事件觸發一次真正的binlog fsync刷盤，預設是1，表示每次commit時binlog都會fsync。

兩階段交易認可

這個兩階段交易認可不是分散式交易的兩階段交易認可，而是在開啟binlog之後，redo與binlog的兩階段交易認可。 兩階段交易認可，首先redo log prepare，然後寫binlog，最後redo log commit.

• 如果redo log prepare之後，binlog之前宕機，則復原事務，日誌如下：

2015-07-29 17:03:18 21957 [Note] Starting crash recovery...2015-07-29 17:03:18 7ffff7fe4780  InnoDB: Starting recovery for XA transactions...2015-07-29 17:03:18 7ffff7fe4780  InnoDB: Transaction 35077 in prepared state after recovery2015-07-29 17:03:18 7ffff7fe4780  InnoDB: Transaction contains changes to 1 rows2015-07-29 17:03:18 7ffff7fe4780  InnoDB: 1 transactions in prepared state after recovery2015-07-29 17:03:18 21957 [Note] Found 1 prepared transaction(s) in InnoDB2015-07-29 17:03:18 21957 [Note] rollback xid ‘MySQLXid\1\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0‘

• 如果binlog寫入之後宕機，則recover事務。

2015-07-29 17:06:23 7ffff7fe4780  InnoDB: Starting recovery for XA transactions...2015-07-29 17:06:23 7ffff7fe4780  InnoDB: Transaction 35590 in prepared state after recovery2015-07-29 17:06:23 7ffff7fe4780  InnoDB: Transaction contains changes to 1 rows2015-07-29 17:06:23 7ffff7fe4780  InnoDB: 1 transactions in prepared state after recovery2015-07-29 17:06:23 22040 [Note] Found 1 prepared transaction(s) in InnoDB2015-07-29 17:06:23 22040 [Note] commit xid ‘MySQLXid\1\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0‘2015-07-29 17:06:23 22040 [Note] Crash recovery finished.

什麼情況下會出現binlog寫入了，但是實際這條資料不存在庫中？

innodb_flush_log_at_trx_commit 為0， sync_binlog=1，此時redo log沒有刷盤，binlog刷盤了，recover的時候不會根據binlog恢複。

所以強烈建議這兩個參數都設定成1.

MySQL兩階段交易認可