概要:1、主備延遲? ? 2铆铆、延遲原因:備壓力大蝶缀,大事務(wù)、并行復(fù)制能力? ? 3算灸、可靠性優(yōu)先
雙 M 結(jié)構(gòu)主備切換:
一扼劈、主備延遲
????主動:軟件升級、主庫按計劃下線菲驴,被動:機(jī)器掉電荐吵。
1、主動切換場景:“同步延遲”時間點赊瞬,時間差 T3-T1:
????1)A 執(zhí)行完成先煎,寫入 binlog T1;
????2) 傳給備庫 B,接收 binlog T2;
????3) B 執(zhí)行完 T3巧涧。
備庫上show slave status 顯示 seconds_behind_master(備庫延遲多少秒)=?binlog 記錄主庫寫入時間.-?備庫取出時間字段值
2薯蝎、時間不一致,不會值不準(zhǔn)?
不會谤绳,備庫連主庫時占锯, SELECT UNIX_TIMESTAMP() 獲主庫時間。發(fā)現(xiàn)不一致自動扣掉
網(wǎng)絡(luò)正常T2-T1 非常小缩筛。延遲來源:備庫接收完 binlog 和執(zhí)行完時間差消略。
備庫消費中轉(zhuǎn)日志(relay log)比主庫生產(chǎn) binlog 慢。哪些原因?qū)е拢?/p>
二瞎抛、主備延遲的來源
1艺演、備庫性能差,20 個主庫在 4 臺桐臊,備庫集中一臺(較少胎撤,對稱部署常見)
? ?????更新請求對 IOPS 壓力,主断凶、備無差別伤提。將備庫設(shè)置為“非雙 1”模式。
2认烁、更新觸發(fā)大量讀操作飘弧。備庫搶資源识藤,主備延遲。
追問 1:對稱部署后(主備機(jī)器一樣)次伶,還有延遲痴昧?
備庫壓力大。主庫提供寫能力冠王,備庫提供讀能力或分析語句
主庫直接影響業(yè)務(wù)赶撰,大家克制,忽視備庫壓力柱彻。備庫上查詢耗 CPU影響同步豪娜,主備延遲,解決辦法:
????1)一主多從哟楷。多幾個從庫分擔(dān)讀壓力(多)
????2)通過 binlog 輸出到外部系統(tǒng)瘤载,如Hadoop提供統(tǒng)計類查詢能力。
保證定期全量備份卖擅。從庫做備份鸣奔。
ps: HA 過程中被選成新主庫為備庫,其他為從庫
追問 2:一主多從惩阶,保證備壓力不超主挎狸,什么情況導(dǎo)致主備延遲?
大事務(wù)断楷。主庫事務(wù)完成才寫binlog锨匆,再傳給備庫。執(zhí)行 10 分鐘冬筒,從庫延遲 10 分鐘恐锣。
? ??1)歸檔類的數(shù)據(jù),空間快滿了舞痰,一次性地刪掉大量侥蒙。晚上執(zhí)行,收到延遲報警。分成多次刪除匀奏。
? ??2)大表 DDL。計劃內(nèi)的 DDL学搜,用 gh-ost 方案(這里娃善,你可以再回顧下第 13 篇文章《為什么表數(shù)據(jù)刪掉一半,表文件大小不變瑞佩?》中的相關(guān)內(nèi)容)聚磺。
追問 3:主庫不做大事務(wù),什么原因會導(dǎo)致主備延遲炬丸?
備庫并行復(fù)制能力(具體下一篇)
三瘫寝、可靠性優(yōu)先策略
雙 M? 1 到 2(HA 系統(tǒng)完成):
1. 判斷備庫 B seconds_behind_master(SBM)小于某個值(如 5 秒)繼續(xù)下一步蜒蕾,否則持續(xù)重試
2. 主庫 A 只讀 readonly =true;直到備庫 B seconds_behind_master 變0為止(耗費時間焕阿,確保SBM足夠羞浞取);
3. 備庫 B可讀寫狀態(tài)readonly = false暮屡;業(yè)務(wù)請求切到備庫 B撤摸。
切換流程有不可用時間。主褒纲、備庫 B 都 readonly 准夷, 完成后恢復(fù)。
主備延遲長達(dá) 30 分鐘莺掠,不判斷直接切換衫嵌,不可用時間長達(dá) 30 分鐘
數(shù)據(jù)可靠性優(yōu)先策略決定。來把不可用時間幾乎降為 0彻秆。
四楔绞、可用性優(yōu)先策略
步驟 3調(diào)最開始執(zhí)行,不等主備數(shù)據(jù)同步掖棉,直接切到備庫 B墓律,可讀寫,沒有不可用時間幔亥,可能不一致:
主庫其他表大量更新耻讽,主備延遲5 秒。自增主鍵 id帕棉,主针肥、備庫都 3 行數(shù)據(jù)。兩條插入:
insert into t(c)? values(4); //香伴。插入c=4 后主備切換
insert into t(c)? values(5);
圖 3 是可用性優(yōu)先策略慰枕,且binlog_format=mixed時的切換流程和數(shù)據(jù)結(jié)果。
設(shè)置binlog_format=row:會記錄新插入所有值具帮,只有一行不一致。兩邊的主備同步的應(yīng)用線程會報錯 duplicate key error 并停止。 (5,4)? (5,5) 都不會被對方執(zhí)行
可靠性優(yōu)于可用性绊率。row 不一致更容易被發(fā)現(xiàn)速侈。 mixed 或 statement 悄悄地不一致。
哪種情況可用性優(yōu)先級高?
(1)庫記錄操作日志。不一致 binlog 修補(bǔ),不會引發(fā)業(yè)務(wù)問題稠通。
(2)庫不可寫導(dǎo)致線上業(yè)務(wù)無法執(zhí)行衬衬。強(qiáng)行切換,事后再補(bǔ)改橘。
改進(jìn)辦法:不依賴這類日志寫入滋尉。降級,寫到本地文件/臨時庫里面
可靠性優(yōu)先唧龄,異常切換
主備延遲 30 分鐘兼砖, A 掉電了切換 B 。
seconds_behind_master=0 才能切換讽挟。系統(tǒng)不可用狀態(tài)也不能切:中轉(zhuǎn)日志沒應(yīng)用完,查詢不到執(zhí)行完事務(wù)丸冕,認(rèn)為“數(shù)據(jù)丟失”耽梅。
隨著中轉(zhuǎn)日志的繼續(xù)應(yīng)用,數(shù)據(jù)恢復(fù)胖烛,查詢到“暫時丟失數(shù)據(jù)的狀態(tài)”不能接受
MySQL 高可用眼姐,可用性是依賴于主備延遲的。
小結(jié)
主備切換佩番。主備延遲情況众旗,改進(jìn)方向。
可靠性趟畏、可用性優(yōu)先策略區(qū)別贡歧。
可靠性優(yōu)先(更建議)。保證數(shù)據(jù)準(zhǔn)確赋秀,數(shù)據(jù)庫服務(wù)底線利朵。減少主備延遲,提升可用性猎莲。
思考題
備庫延遲監(jiān)控绍弟,執(zhí)行 show slave status,采集 seconds_behind_master 值著洼。
維護(hù)備庫樟遣,延遲監(jiān)控類似圖 6,什么原因?qū)е履厣眢裕吭趺创_認(rèn)豹悬?
(1)大事務(wù)(大表 DDL、一個事務(wù)操作很多行)展鸡;
(2)備庫長事務(wù),比如? begin; select * from t? limit 1;?不動了.這時主庫對表 t 加字段埃难,即使表小莹弊,DDL備庫被堵住
評論1
主從延遲情況:
1.主庫DML并發(fā)大,從庫qps高
2.從庫服務(wù)器配置差或者一臺服務(wù)器上幾臺從庫(資源競爭激烈,特別是io)
3.主涤久、從庫參數(shù)配置不一樣
4.大事務(wù)(DDL)
5.從庫上備份
6.表上無主鍵(主庫用索引update,備庫回放只能全表掃描,可調(diào)整slave_rows_search_algorithms適當(dāng)優(yōu)化)
7.設(shè)置延遲備庫
8.備庫空間不足
看曲線,是從庫大事務(wù),或大表無主鍵,時間增長,second_behind_master也有規(guī)律增長
評論2
1,備庫備份產(chǎn)生MDL鎖忍弛,復(fù)制線程被堵塞响迂,kill備份線程暢快。備份產(chǎn)生非共享鎖不是短時間就釋放细疚?為什么堵的時間那么長蔗彤?像是死鎖
2,歸檔程序用共享存儲疯兼,占用導(dǎo)致然遏,同樣連接該存儲上數(shù)據(jù)庫寫瓶頸,寫中繼日志慢(沒滯留)吧彪,應(yīng)用日志線程正常待侵。產(chǎn)生備庫延遲。當(dāng)時第一反應(yīng)是網(wǎng)絡(luò)帶寬被打滿了姨裸,確認(rèn)沒問題秧倾。看存儲IOPS傀缩。定位批量寫入那先。
評論3
大事務(wù),second_behind_master當(dāng)前系統(tǒng)時間戳減sql_thread執(zhí)行binglog event時間戳
SBM判斷主從同步有嚴(yán)重問題赡艰,從庫不會馬上知道和主庫連接不通售淡,從庫有salve_net_timeout=x秒 (設(shè)小,檢測與主庫通訊)瞄摊⊙郑或用pt-hearbeat檢測主從延遲。
mysql主從復(fù)制换帜,連接(重連)時從庫告訴主庫信息楔壤,之后主庫主動(根據(jù)要求發(fā)日志binlog?)靠備庫輪詢,有時間差