MySQL 5.6主從報(bào)錯(cuò)的實(shí)戰(zhàn)記錄
1. 問題現(xiàn)象
版本:MySQL 5.6,采用傳統(tǒng) binlog file & pos 方式配置的主從復(fù)制結(jié)構(gòu)。

實(shí)例重啟后,主從復(fù)制報(bào)錯(cuò)如上圖所示。
2. 錯(cuò)誤含義
錯(cuò)誤分為2部分。
第一部分
- Client requested master to start replication from position > file size;
- the first event 'mysql-bin.000398' at 163800795,the last event read from './mysql-binlog.000398' at 4,the last byte read from './mysql-bin.000398' at 4'
第一部分
這部分來源于主庫的DUMP線程函數(shù)
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)
{
set_fatal_error(errmsg);
return 1;
}
size= my_b_filelength(&cache);
end_io_cache(&cache);
mysql_file_close(file, MYF(MY_WME));
if (m_start_pos > size)
{
set_fatal_error("Client requested master to start replication from "
"position > file size");
return 1;
}
關(guān)鍵就是m_start_pos和size兩個(gè)值,其中m_start_pos來源于從庫需要讀取的位點(diǎn)。而size則是本binlog文件的大小,那么很容易理解如果io線程需要的pos點(diǎn)比本binlog文件的大小還要大,那么自然不對(duì)。
第二部分
這部分也來源于DUMP線程
mysql_binlog_send
->sender.run()
->Binlog_sender::init
->while (!has_error() && !m_thd->killed)
#如果正常這里開始循環(huán)讀取binlog event,如果前面出錯(cuò)則直接繼續(xù)后面邏輯
#如果有讀取錯(cuò)誤則報(bào)錯(cuò)
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,實(shí)際上m_start_pos就是和前面報(bào)錯(cuò)一致的來自從庫需要讀取的位點(diǎn)信息,而m_last_pos來自dump線程,就是最后讀取的位置,顯然這里一次都沒有讀取,因此位置為最開始的pos 4。
3. 可能的原因
分析后覺得最有可能原因應(yīng)該和sync_binlog 有關(guān)。
如果我們沒有設(shè)置為1,那么可能os cache沒有刷盤,如果主庫服務(wù)器直接crash重啟很容易就遇到這種問題。
稍微google查詢了一下發(fā)現(xiàn)很大部分出現(xiàn)這種錯(cuò)誤都是由于服務(wù)器crash且sync_binlog 沒設(shè)置為 1導(dǎo)致的。
這也證明我們的說法。
最后查看問題數(shù)據(jù)庫的主庫確實(shí)沒有設(shè)置為雙1。
那么通過這個(gè)小案例,我們已經(jīng)更加深刻體會(huì)到設(shè)置雙1的重要性。
總結(jié)
到此這篇關(guān)于MySQL 5.6主從報(bào)錯(cuò)的文章就介紹到這了,更多相關(guān)MySQL5.6主從報(bào)錯(cuò)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
詳解MySQL單實(shí)例和多實(shí)例啟動(dòng)腳本
這篇文章主要介紹了MySQL單實(shí)例和多實(shí)例啟動(dòng)腳本,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2023-08-08
Centos7下安裝MySQL8.0.23的步驟(小白入門級(jí)別)
這篇文章主要介紹了Centos7下安裝MySQL8.0.23的步驟(小白入門級(jí)別),本文通過圖文并茂的形式給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2021-01-01
rpm -ivh方式安裝mysql并修改數(shù)據(jù)存儲(chǔ)位置的實(shí)現(xiàn)
在Linux環(huán)境下進(jìn)行MySQL的安裝可以使用不同的方式,但在本文中我們將關(guān)注一種特定的方式,即通過RPM包的方式進(jìn)行安裝,本文主要介紹了rpm -ivh方式安裝mysql并修改數(shù)據(jù)存儲(chǔ)位置的實(shí)現(xiàn),感興趣的可以了解一下2023-09-09
MySQL派生表合并優(yōu)化的原理和實(shí)現(xiàn)過程
本文從一個(gè)案例出發(fā)梳理了MySQL派生表合并優(yōu)化的流程實(shí)現(xiàn)和優(yōu)化原理,并對(duì)優(yōu)化前后同一條SQL語句在代碼層面的類實(shí)例映射關(guān)系進(jìn)行了對(duì)比,這篇文章主要介紹了MySQL派生表合并優(yōu)化的原理和實(shí)現(xiàn),需要的朋友可以參考下2024-07-07
MySQL實(shí)時(shí)監(jiān)控工具orztop的使用介紹
這篇文章主要給大家介紹了MySQL實(shí)時(shí)監(jiān)控工具orztop的使用,文中給出了詳細(xì)的介紹,相信對(duì)大家的學(xué)習(xí)具有一定的參考借鑒價(jià)值,有需要的朋友可以參考借鑒,下面來一起看看吧。2017-01-01

