master_info與relay_info對Mysql數據庫有什么影響

master_info與relay_info對Mysql數據庫有什么影響，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

在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個參數控制刷新：

• 默認為10000，即每10000次sync_relay_log事件會刷新到磁盤。




• 如果值>0, MySQL SERVER 同步它的relay log 到磁盤(寫入中繼日志,使用fdatasync()) 在every sync_relay_log events are written to the relay log.） 

•    

• 當設置為1時，slave的I/O線程每次接收到master發送過來的binlog日志都要寫入系統緩沖區，然后刷入relay log中繼日志里，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務，但會造成  

• 磁盤的大量I/O。

• 
  

• 當設置為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事務原理等，相對還比較復雜，有點難以理解。

     只有當我們了解了這些丟數據的場景，才能更好的去學習， 并解決這些問題。

關于master_info與relay_info對Mysql數據庫有什么影響問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。