MySQL當機可能導緻2種丢資料的場景

1、引擎層送出了，但BINLOG沒寫入，備庫丢事務

2、引擎層沒有PREPARE，但BINLOG寫入，主庫丢事務

即使我們将參數設定成<code>innodb_flush_log_at_trx_commit =1</code> 和 <code>sync_binlog = 1</code>，也還會面臨這樣一種情況：主庫crash時還有binlog沒傳遞到備庫，如果我們直接提升備庫為主庫，同樣會導緻主備不一緻，老主庫必須根據新主庫重做，才能恢複到一緻的狀态。針對這種場景，我們可以通過開啟semisync的方式來解決，一種可行的方案描述如下：

設定雙1強持久化配置;

我們将semisync的逾時時間設到極大值，同時使用semisync AFTER_SYNC模式，即使用者線程在寫入binlog後，引擎層送出前等待備庫ACK；

基于步驟1的配置，我們可以保證在主庫crash時，所有老主庫比備庫多出來的事務都處于prepare狀态；

備庫完全apply日志後，記下其執行到的relay log對應的位點，然後将備庫提升為新主庫；

将老主庫的最後一個binlog進行截斷，截斷的位點即為步驟3記錄的位點;

啟動老主庫，那些已經傳遞到備庫的事務都會送出掉，未傳遞到備庫的binlog都會復原掉。

本文轉自 DBAspace 51CTO部落格，原文連結:http://blog.51cto.com/dbaspace/1867865