概要：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?）靠備庫輪詢，有時間差
