【Mysql】master_info 與 relay_info對資料庫的影響

小亮520cl發表於2016-08-05
MySqlAST資料庫
在MySQL 5.6.2之前，slave記錄的master資訊以及slave應用binlog的資訊存放在檔案中，即master.info與relay-log.info。在5.6.2版本之後，允許記錄到table中，引數設定如下：
master-info-repository  = TABLE    ---FILE表示以檔案方式
relay-log-info-repository = TABLE   ---FILE表示以檔案方式
對應的表分別為mysql.slave_master_info與mysql.slave_relay_log_info，且這兩個表均為innodb引擎表。

master info與relay info還有3個引數控制重新整理：
  1. sync_relay_log：控制著relay log二進位制日誌的寫入重新整理操作
      1. 預設為10000，即每10000次sync_relay_log事件會重新整理到磁碟。

    2. 如果值>0, MySQL SERVER 同步它的relay log 到磁碟(寫入中繼日誌,使用fdatasync()) 在every sync_relay_log events are written to the relay log.） 
    3.    
    4. 當設定為1時，slave的I/O執行緒每次接收到master傳送過來的binlog日誌都要寫入系統緩衝區，然後刷入relay log中繼日誌裡，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務，但會造成  
    5. 磁碟的大量I/O。

    7. 當設定為0時，並不是馬上就刷入中繼日誌裡，而是由作業系統決定何時來寫入，雖然安全性降低了，但減少了大量的磁碟I/O操作。


sync_master_info:控制master_info資訊的更新操作
若master-info-repository為FILE，當設定為0，則每次sync_master_info事件都會重新整理到磁碟，預設為10000次重新整理到磁碟；
 若master-info-repository為TABLE，當設定為0，則表不做任何更新，設定為1，則每次事件會更新表 #預設為10000

sync_relay_log_info：控制relay_log_info資訊的更新操作
若relay_log_info_repository為FILE，當設定為0，交由OS重新整理磁碟，預設為10000次重新整理到磁碟；
若relay_log_info_repository為TABLE，且為INNODB儲存，則無論為任何值，則都每次evnet都會更新表。


master當機後無法及時恢復造成的資料丟失

   當master出現故障後，binlog未及時傳到slave，或者各個slave收到的binlog不一致。且master無法在第一時間恢復，這個時候怎麼辦？
   如果master不切換，則整個資料庫只能只讀，影響應用的執行。
   如果將別的slave提升為新的master，那麼原master未來得及傳到slave的binlog的資料則會丟失，並且還涉及到下面2個問題。
      1.各個slave之間接收到的binlog不一致，如果強制拉起一個slave，則slave之間資料會不一致。
      2.原master恢復正常後，由於新的master日誌丟棄了部分原master的binlog日誌，這些多出來的binlog日誌怎麼處理，重新搭建環境？

對於上面出現的問題，一種方法是確保binlog傳到從庫，或者說保證主庫的binlog有多個複製。第二種方法就是允許資料丟失，制定一定的策略，保證最小化丟失資料。

1.確保binlog全部傳到從庫
   方案一：使用semi sync（半同步）方式，事務提交後，必須要傳到slave，事務才能算結束。對效能影響很大，依賴網路適合小tps系統。
   方案二：雙寫binlog，透過DBDR OS層的檔案系統複製到備機，或者使用共享盤儲存binlog日誌。
   方案三：在資料層做文章，比如保證資料庫寫成功後，再非同步佇列的方式寫一份，部分業務可以藉助設計和資料流解決。

2.保證資料最小化丟失
   上面的方案設計及架構比較複雜，如果能容忍資料的丟失，可以考慮使用淘寶的TMHA複製管理工具。
       當master當機後，TMHA會選擇一個binlog接收最大的slave作為master。當原master當機恢復後，透過binlog的逆向應用，把原master上多執行的事務回退掉。

3.總結

     透過上面的總結分析，MySQL丟資料的場景是五花八門，涉及到單庫的丟資料場景、主從的丟資料場景以及MySQL內部XA事務原理等，相對還比較複雜，有點難以理解。
     只有當我們瞭解了這些丟資料的場景，才能更好的去學習， 並解決這些問題。


參考文件：
http://blog.itpub.net/25704976/viewspace-1318714/

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29096438/viewspace-2123053/，如需轉載，請註明出處，否則將追究法律責任。

相關文章