鏈接:http://blog.csdn.net/yumushui/article/details/42742461

今天在搭建一個MySQL master-slave集群時，執行了change master命令，然后又 start slave 啟動slave服務，結果查看salve狀態就出現錯誤了：

?

?

mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Master_Host: 192.168.62.108 Master_User: repl Master_Port: 3307 Connect_Retry: 60 Master_Log_File: mysql-bin.000544 Read_Master_Log_Pos: 76175557 Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-bin.000544 Slave_IO_Running: No Slave_SQL_Running: Yes 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: 76175557 Relay_Log_Space: 107 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: 621083307 1 row in set (0.00 sec) 錯誤提示的內容，按照字面意思： 最后的IO錯誤為 1236； 當從binlog 中讀取數據時，master返回一個1236的錯誤——在binlog索引文件中不能找到第一個日志文件。 之前我遇到這個錯誤，是因為搭建salve庫時，使用的備份是master庫7天前的備份，binlog設置默認保留天數為7天，過期的binlog日志文件都會被刪除了。所以當時找不到最初binlog日志文件，所以提示這個錯誤。 于是我登錄到 mysql master服務器上確認，mysql-bin.000544日志文件就是今天早上的，目前master正在寫入的日志是mysql-bin.000550，肯定是存在，按說是可以讀到的。 我查看是否還有其他原因，在網上一篇文章中看到，提示這樣錯誤的原因可能是binlog日志文件不存在，或者binlog的名稱沒有寫對，有空格。這個說法提醒了我，我的操作都是有記錄的，趕快去確認開始執行的 change master 命令，結果發現是因為 一開始在進行 change master 命令時，binlog文件 的名稱多一個空格，造成了binlog文件名稱發生了變化，所以就找不到了。 處理方法：重新stop slave, 修改 change master確保binlog日志文件名稱沒有空格是正確的, 然后start slave 后狀態正常。 通過這次故障，可以看出DBA在進行日常操作和故障處理時，還是需要更多的耐心和細心，這樣才能避免更多的問題，盡快解決已經發生的問題。 ************************************************ 附：出現問題時查詢到的網頁內容為 網頁地址：http://blog.chinaunix.net/uid-20778583-id-3874530.html MySQL Slave復制故障3例

1.Sandy颶風導致NYC機房停電，重啟后看到的日志如下：?

121101 16:35:25 [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: 1236

121101 16:35:25 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.014497', position?38542146

121101 16:41:36 [Note] Error reading relay log event: slave SQL thread was killed

?

然后看binlog如下：

# at?38539267

#121101 13:11:04 server id 1 ?end_log_pos?38539294?? ? ?Xid = 934362432

COMMIT/*!*/;

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

master突然當機造成的master的pos要小于slave的錯誤日志記錄的pos，mysql-bin.014497的最后一個位置是: end_log_pos 38539294，但沒有被commit，所以上一個是?38539267?那么直接設pos為master的最后有效的位置即可，

change master to master_log_file='mysql-bin.014497',master_log_pos=38539267;

但也有可能情況相反，可能slave丟了部分數據或延遲，此時把pos往前移，反復試驗即可。

?

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

logfile有空格，或是master上對應的Log被刪了。

?

3. Show processlist?看到很多sleep,可能是應用代碼做完query之后沒用close()主動關閉鏈接。這樣會一直到timeout才斷掉，但這個timeout太小的話，會導致mysql has gone away?這種錯誤。

轉載于:https://www.cnblogs.com/microcat/p/8432257.html

總結

以上是生活随笔為你收集整理的MySQL--从库启动复制报错1236的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。