MySQL 5 6主從報錯的實戰記錄

版本：mysql 5.6，採用傳統 binlog file & pos 方式配置的主從複製結構。

例項重啟後，主從複製報錯如上圖所示。

錯誤分為2部分。

第一部分

這部分**於主庫的dump執行緒函式

mysql_binlog_send

->sender.run()

->binlog_sender::init

->binlog_sender::check_start_file

if ((file= open_binlog_file(&cache, m_linfo.log_file_name, &errmsg)) < 0)

size= my_b_filelength(&cache);

end_io_cache(&cache);

mysql_file_close(file, myf(my_wme));

if (m_start_pos > si程式設計客棧ze)

關鍵就是m_start_pos和size兩個值，其中m_start_pos**於從庫需要讀取的位點。而size則是本binlog檔案的大小，那麼很容易理解如果io執行緒需要的pos點比本binlog檔案的大小還要大，那麼自然不對。

第二部分

這部分也**於dump執行緒

mysql_binlog_send

->sender.run()

->binlog_sender::init

->while (!has_error() && !m_thd->killed)

#如果正常這裡開始迴圈讀取binlog event，如果前面出錯則直接繼續後面邏輯

#如果有讀取錯誤則報錯

my_snprintf(error_text, sizeof(error_text),

"%s; the first event '%s' at %lld, "

"the last event read from '%s程式設計客棧' at %lld, "

"the last byte read from '%s' at %lld.",

m_errmsg,

m_start_file, m_start_pos, m_last_file, m_last_pos,

log_file, my_b_tell(&log_cache));

這裡我們主要看看m_start_pos和m_last_pos，實際上m_start_pos就是和前面報錯一致的來自從庫需要讀取的位點資訊，而m_last_pos來自dump執行緒，就是最後讀取的位置，顯然這裡一次都沒有讀取，因此位置為最開始的pos 4。

分析後覺得最有可能原因應該和sync_binlog 有關。

如果我們沒有設定為1，那麼可能os cache沒有刷盤，如果主庫伺服器直接crash重啟很容易就遇到這種問題。

稍微google查詢了一下發現很大部分出現這種錯誤都是由於伺服器crash且sync_binlog 沒設定為 1導致的。

這也證明我們的說法。

最後檢視問題資料庫的主庫確實沒有設定為雙1。

那麼通過這個小案例，我們已經更加深刻體會到設定雙1的重要性。