MySQL主從複製報錯：Got fatal error 1236 from master when reading data from

lhrbest發表於2019-07-22
MySqlGoErrorAST


Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'


備庫檢查報錯： 

(root@localhost) [sys]> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 127.0.0.1
                  Master_User: repl
                  Master_Port: 3316
                Connect_Retry: 60
              Master_Log_File: rhel6lhr-bin.000003
          Read_Master_Log_Pos: 154
               Relay_Log_File: rhel6lhr-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: rhel6lhr-bin.000003
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 154
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 57193316
                  Master_UUID: 1dc4b050-ac4d-11e9-ab99-000c29d51a2a
             Master_Info_File: /usr/local/mysql57/mysql5719/data57193317/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 190722 15:06:09
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version:


 解決：

在 source 那邊，執行： 

flush logs;
show master status;File

在 target 端，執行： 

stop slave ;
CHANGE MASTER TO MASTER_LOG_FILE='testdbbinlog.000008',MASTER_LOG_POS=107;
start slave ;
show slave status \G

 

一切正常。



【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 大小 


Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the start event position from 'mysql-bin.006730' at 290066246, the last event was read from '/u01/my3309/log/mysql-bin.006730

【 原因 】
   此類報錯和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“。
【 如何解決 】
 需要確保主備配置一樣，然後嘗試調大該引數的值。 


set global max_allowed_packet =1*1024*1024*1024;
 stop slave;start slave

另外，5.6 版本中的  slave_max_allowed_packet_size  引數控制slave 可以接收的最大的packet 大小，該值通常大於而且可以覆蓋 max_allowed_packet 的配置, 進而減少由於上面的問題導致主從複製中斷。

2.2 slave 在主庫找不到binlog檔案   


Got fatal error 1236 from master when reading data from binary log:

【 原因 】
 該錯誤發生在從庫的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 主庫空間問題， 日誌被截斷 



Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the start event position from 'mysql-bin.006730' at 290066434, the last event was read from '/u01/my3309/log/mysql-bin.006730

【 原因 】
 該錯誤和主庫的空間問題和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初始化的位置開始 


stop slave;
 change master to master_log_file='mysql-bin.006731', master_log_pos=4;start slave;

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


120611 20:39:38 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 
 120611 20:39:38 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236120611 20:39:38 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000143', position 664526789

【原因】
 該問題也是和sync_binlog=N不等於1有關，多出現在主機異常crash ，比如磁碟損壞，raid 卡損壞，或者主機異常掉電導致binlog 未及時同步到磁碟。從庫讀取了主庫binlog file中的不存在的binlog position ，一般比binlogfile 的end position 的值還要大。
【 如何解決 】
1 在從庫重新指向到主庫下一個可用的binlog file 並且從binlog file初始化的位置開始 


stop slave;
 change master to master_log_file='mysql-bin.000144', master_log_pos=4;start slave;

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

 




About Me

........................................................................................................................

● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除

● 本文在itpub、部落格園、CSDN和個人微 信公眾號（ xiaomaimiaolhr ）上有同步更新

● 本文itpub地址： http://blog.itpub.net/26736162

● 本文部落格園地址： http://www.cnblogs.com/lhrbest

● 本文CSDN地址： https://blog.csdn.net/lihuarongaini

● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/

● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/

● DBA寶典今日頭條號地址：

........................................................................................................................

● QQ群號： 230161599 （滿） 、618766405

● 微 信群：可加我微 信，我拉大家進群，非誠勿擾

● 聯絡我請加QQ好友 （ 646634621 ） ，註明新增緣由

● 於 2019-07-01 06:00 ~ 2019-07-31 24:00 在西安完成

● 最新修改時間：2019-07-01 06:00 ~ 2019-07-31 24:00

● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解

● 版權所有，歡迎分享本文，轉載請保留出處

........................................................................................................................

● 小麥苗的微店 ：

● 小麥苗出版的資料庫類叢書 ： http://blog.itpub.net/26736162/viewspace-2142121/

● 小麥苗OCP、OCM、高可用網路班 ： http://blog.itpub.net/26736162/viewspace-2148098/

● 小麥苗騰訊課堂主頁 ： https://lhr.ke.qq.com/

........................................................................................................................

使用 微 信客戶端 掃描下面的二維碼來關注小麥苗的微 信公眾號（ xiaomaimiaolhr ）及QQ群（DBA寶典）、新增小麥苗微 信， 學習最實用的資料庫技術。

........................................................................................................................

歡迎與我聯絡

 

 



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

相關文章