【MySQL】Got fatal error 1236原因和解決方法

一 前言

  mysql 的主從複制作為一項高可用特性，用于将主庫的資料同步到從庫，在維護主從複制資料庫叢集的時候，作為專職的mysql dba，筆者相信大多數人都會遇到“got fatal error 1236 from master when reading data from binary log” 這類的報錯/報警。本文整理了常見的幾種 error 1236 報錯，并給出相應的解決方法，有所不足之處，當然也希望各位讀者朋友指正。

二 常見的error 1236 報錯

2.1 logevent超過max_allowed_packet 大小

【原因】

   此類報錯和max_allowed_packet相關。首先max_allowed_packet控制着主從複制過程中，一個語句産生的二進制binlog event大小，它的值必須是1024的倍數 。出現此類錯誤的常見原因是

 1 該參數在主備庫的配置大小不一樣，主庫的配置值大于從庫的配置值。 從主庫傳遞到備庫的binlog event大小超過了主庫或者備庫的max_allowed_packet大小。

 2 主庫有大量資料寫入時，比如在主庫上執行 laod data，insert into .... select 語句，産生大事務。

當主庫向從庫傳遞一個比從庫的max_allowed_packet 大的packet ，從庫接收該packet失敗，并報 “log event entry exceeded max_allowed_packet“。

【如何解決】

 需要確定主備配置一樣，然後嘗試調大該參數的值。

2.2 slave 在主庫找不到binlog檔案 

 該錯誤發生在從庫的io程序從主庫拉取日志時，發現主庫的mysql_bin.index檔案中第一個檔案不存在。出現此類報錯可能是由于你的slave 由于某種原因停止了好長一段是時間，當你重新開機slave 複制的時候，在主庫上找不到相應的binlog ,會報此類錯誤。或者是由于某些設定主庫上的binlog被删除了，導緻從庫擷取不到對應的binglog file。

 1 為了避免資料丢失，需要重新搭建slave 。

 2 注意主庫binlog的清理政策，選擇基于時間過期的删除方式還是基于空間使用率的删除方式。

  不要使用rm -fr 指令删除binlog file，這樣不會同步修改mysql_bin.index 記錄的binlog 條目。在删除binlog的時候確定主庫保留了從庫 show slave status 的relay_master_log_file對應的binlog file。

2.3 主庫空間問題，日志被截斷

 該錯誤和主庫的空間問題和sync_binlog配置有關，當主庫 sync_binlog=n不等于1且磁盤空間滿時,mysql每寫n次binary log，系統才會同步到磁盤，但是由于存儲日志的磁盤空間滿而導緻mysql 沒有将日志完全寫入磁盤，binlog event被截斷。slave 讀取該binlog file時就會報錯"binlog truncated in the middle of event;"

 當sync_binlog 的預設值是0，像作業系統刷其他檔案的機制一樣，mysql不會同步到磁盤中去而是依賴作業系統來重新整理binary log。

 當sync_binlog =n (n>0) ，mysql 在每寫 n次 二進制日志binary log時，會使用fdatasync()函數将它的寫二進制日志binary log同步到磁盤中去。

 在從庫重新指向到主庫下一個可用的binlog file 并且從binlog file初始化的位置開始

2.4 主庫異常斷電,從庫讀取錯誤的position

 該問題也是和sync_binlog=n不等于1有關，多出現在主機異常crash ，比如磁盤損壞，raid 卡損壞，或者主機異常掉電導緻binlog 未及時同步到磁盤。從庫讀取了主庫binlog file中的不存在的binlog position ，一般比binlogfile 的end position 的值還要大。

1 在從庫重新指向到主庫下一個可用的binlog file 并且從binlog file初始化的位置開始

2 主備庫設定 sync_binlog=1，但是設定為1的時候，會帶來性能下降。