MySQL 5.6主從報(bào)錯(cuò)的實(shí)戰(zhàn)記錄
1. 問(wèn)題現(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'
第一部分
這部分來(lái)源于主庫(kù)的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來(lái)源于從庫(kù)需要讀取的位點(diǎn)。而size則是本binlog文件的大小,那么很容易理解如果io線程需要的pos點(diǎn)比本binlog文件的大小還要大,那么自然不對(duì)。
第二部分
這部分也來(lái)源于DUMP線程
mysql_binlog_send
->sender.run()
->Binlog_sender::init
->while (!has_error() && !m_thd->killed)
#如果正常這里開(kāi)始循環(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ò)一致的來(lái)自從庫(kù)需要讀取的位點(diǎn)信息,而m_last_pos來(lái)自dump線程,就是最后讀取的位置,顯然這里一次都沒(méi)有讀取,因此位置為最開(kāi)始的pos 4。
3. 可能的原因
分析后覺(jué)得最有可能原因應(yīng)該和sync_binlog 有關(guān)。
如果我們沒(méi)有設(shè)置為1,那么可能os cache沒(méi)有刷盤(pán),如果主庫(kù)服務(wù)器直接crash重啟很容易就遇到這種問(wèn)題。
稍微google查詢了一下發(fā)現(xiàn)很大部分出現(xiàn)這種錯(cuò)誤都是由于服務(wù)器crash且sync_binlog 沒(méi)設(shè)置為 1導(dǎo)致的。
這也證明我們的說(shuō)法。
最后查看問(wèn)題數(shù)據(jù)庫(kù)的主庫(kù)確實(shí)沒(méi)有設(shè)置為雙1。
那么通過(guò)這個(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)文章希望大家以后多多支持腳本之家!
- mysql5.6 主從復(fù)制同步詳細(xì)配置(圖文)
- MySQL5.6 數(shù)據(jù)庫(kù)主從同步安裝與配置詳解(Master/Slave)
- MySQL5.6 Replication主從復(fù)制(讀寫(xiě)分離) 配置完整版
- MySQL5.6主從復(fù)制(mysql數(shù)據(jù)同步配置)
- mysql 5.6.14主從復(fù)制(也稱(chēng)mysql AB復(fù)制)環(huán)境配置方法
- MYSQL5.6.33數(shù)據(jù)庫(kù)主從(Master/Slave)同步安裝與配置詳解(Master-Linux Slave-windows7)
相關(guān)文章
詳解MySQL單實(shí)例和多實(shí)例啟動(dòng)腳本
這篇文章主要介紹了MySQL單實(shí)例和多實(shí)例啟動(dòng)腳本,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2023-08-08
Centos7下安裝MySQL8.0.23的步驟(小白入門(mén)級(jí)別)
這篇文章主要介紹了Centos7下安裝MySQL8.0.23的步驟(小白入門(mén)級(jí)別),本文通過(guò)圖文并茂的形式給大家介紹的非常詳細(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)注一種特定的方式,即通過(guò)RPM包的方式進(jìn)行安裝,本文主要介紹了rpm -ivh方式安裝mysql并修改數(shù)據(jù)存儲(chǔ)位置的實(shí)現(xiàn),感興趣的可以了解一下2023-09-09
MySQL派生表合并優(yōu)化的原理和實(shí)現(xiàn)過(guò)程
本文從一個(gè)案例出發(fā)梳理了MySQL派生表合并優(yōu)化的流程實(shí)現(xiàn)和優(yōu)化原理,并對(duì)優(yōu)化前后同一條SQL語(yǔ)句在代碼層面的類(lèi)實(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à)值,有需要的朋友可以參考借鑒,下面來(lái)一起看看吧。2017-01-01

