MySQL 主從一直是面試?？停锩娴闹R(shí)點(diǎn)雖然基礎(chǔ)，但是能回答全的同學(xué)不多。
企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的，是企業(yè)文化與產(chǎn)品對(duì)外擴(kuò)展宣傳的重要窗口，一個(gè)合格的網(wǎng)站不僅僅能為公司帶來(lái)巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺(tái)，創(chuàng)新互聯(lián)建站面向各種領(lǐng)域：成都餐廳設(shè)計(jì)等成都網(wǎng)站設(shè)計(jì)公司、全網(wǎng)整合營(yíng)銷推廣解決方案、網(wǎng)站設(shè)計(jì)等建站排名服務(wù)。
比如樓哥之前面試小米，就被問(wèn)到過(guò)主從復(fù)制的原理，以及主從延遲的解決方案，因?yàn)榛卮鸬姆浅２诲e(cuò)，給面試官留下非常好的印象。你之前面試，有遇到過(guò)哪些 MySQL 主從的問(wèn)題呢？
所謂 MySQL 主從，就是建立兩個(gè)完全一樣的數(shù)據(jù)庫(kù)，一個(gè)是主庫(kù)，一個(gè)是從庫(kù)， 主庫(kù)對(duì)外提供讀寫(xiě)的操作，從庫(kù)對(duì)外提供讀的操作 ，下面是一主一從模式：
對(duì)于數(shù)據(jù)庫(kù)單機(jī)部署，在 4 核 8G 的機(jī)器上運(yùn)行 MySQL 5.7 時(shí)，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當(dāng)遇到一些活動(dòng)時(shí)，查詢流量驟然，就需要進(jìn)行主從分離。
大部分系統(tǒng)的訪問(wèn)模型是讀多寫(xiě)少，讀寫(xiě)請(qǐng)求量的差距可能達(dá)到幾個(gè)數(shù)量級(jí)，所以我們可以通過(guò)一主多從的方式， 主庫(kù)只負(fù)責(zé)寫(xiě)入和部分核心邏輯的查詢，多個(gè)從庫(kù)只負(fù)責(zé)查詢，提升查詢性能，降低主庫(kù)壓力。
MySQL 主從還能做到服務(wù)高可用，當(dāng)主庫(kù)宕機(jī)時(shí)，從庫(kù)可以切成主庫(kù)，保證服務(wù)的高可用，然后主庫(kù)也可以做數(shù)據(jù)的容災(zāi)備份。
整體場(chǎng)景總結(jié)如下：
MySQL 的主從復(fù)制是依賴于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤(pán)上二進(jìn)制日志文件。
主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫(kù)傳輸?shù)綇膸?kù)上，一般這個(gè)過(guò)程是異步的，即主庫(kù)上的操作不會(huì)等待 binlog 同步的完成。
詳細(xì)流程如下：
當(dāng)主庫(kù)和從庫(kù)數(shù)據(jù)同步時(shí)，突然中斷怎么辦？因?yàn)橹鲙?kù)與從庫(kù)之間維持了一個(gè)長(zhǎng)鏈接，主庫(kù)內(nèi)部有一個(gè)線程，專門(mén)服務(wù)于從庫(kù)的這個(gè)長(zhǎng)鏈接的。
對(duì)于下面的情況，假如主庫(kù)執(zhí)行如下 SQL，其中 a 和 create_time 都是索引：
我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來(lái)的數(shù)據(jù)一般是不一樣的。
所以就會(huì)存在這種情況：在 binlog = statement 格式時(shí)，主庫(kù)在執(zhí)行這條 SQL 時(shí)，使用的是索引 a，而從庫(kù)在執(zhí)行這條 SQL 時(shí)，使用了索引 create_time，最后主從數(shù)據(jù)不一致了。
那么我們改如何解決呢？
可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個(gè) event:Table_map 和 Delete_rows。
Table_map event 說(shuō)明要操作的表，Delete_rows event用于定義要?jiǎng)h除的行為，記錄刪除的具體行數(shù)。 row 格式的 binlog 記錄的就是要?jiǎng)h除的主鍵 ID 信息，因此不會(huì)出現(xiàn)主從不一致的問(wèn)題。
但是如果 SQL 刪除 10 萬(wàn)行數(shù)據(jù)，使用 row 格式就會(huì)很占空間的，10 萬(wàn)條數(shù)據(jù)都在 binlog 里面，寫(xiě) binlog 的時(shí)候也很耗 IO。但是 statement 格式的 binlog 可能會(huì)導(dǎo)致數(shù)據(jù)不一致。
設(shè)計(jì) MySQL 的大叔想了一個(gè)折中的方案，mixed 格式的 binlog，其實(shí)就是 row 和 statement 格式混合使用， 當(dāng) MySQL 判斷可能數(shù)據(jù)不一致時(shí)，就用 row 格式，否則使用就用 statement 格式。
有時(shí)候我們遇到從數(shù)據(jù)庫(kù)中獲取不到信息的詭異問(wèn)題時(shí)，會(huì)糾結(jié)于代碼中是否有一些邏輯會(huì)把之前寫(xiě)入的內(nèi)容刪除，但是你又會(huì)發(fā)現(xiàn)，過(guò)了一段時(shí)間再去查詢時(shí)又可以讀到數(shù)據(jù)了，這基本上就是主從延遲在作怪。
主從延遲，其實(shí)就是“從庫(kù)回放” 完成的時(shí)間，與 “主庫(kù)寫(xiě) binlog” 完成時(shí)間的差值， 會(huì)導(dǎo)致從庫(kù)查詢的數(shù)據(jù)，和主庫(kù)的不一致 。
談到 MySQL 數(shù)據(jù)庫(kù)主從同步延遲原理，得從 MySQL 的主從復(fù)制原理說(shuō)起：
總結(jié)一下主從延遲的主要原因 ：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當(dāng)主庫(kù)的 TPS 并發(fā)較高，產(chǎn)生的 DDL 數(shù)量超過(guò)從庫(kù)一個(gè) SQL 線程所能承受的范圍，那么延時(shí)就產(chǎn)生了，當(dāng)然還有就是可能與從庫(kù)的大型 query 語(yǔ)句產(chǎn)生了鎖等待。
我們一般會(huì)把從庫(kù)落后的時(shí)間作為一個(gè)重點(diǎn)的數(shù)據(jù)庫(kù)指標(biāo)做監(jiān)控和報(bào)警，正常的時(shí)間是在毫秒級(jí)別，一旦落后的時(shí)間達(dá)到了秒級(jí)別就需要告警了。
解決該問(wèn)題的方法，除了縮短主從延遲的時(shí)間，還有一些其它的方法，基本原理都是盡量不查詢從庫(kù)。
具體解決方案如下：
在實(shí)際應(yīng)用場(chǎng)景中，對(duì)于一些非常核心的場(chǎng)景，比如庫(kù)存，支付訂單等，需要直接查詢從庫(kù)，其它非核心場(chǎng)景，就不要去查主庫(kù)了。
兩臺(tái)機(jī)器 A 和 B，A 為主庫(kù)，負(fù)責(zé)讀寫(xiě)，B 為從庫(kù)，負(fù)責(zé)讀數(shù)據(jù)。
如果 A 庫(kù)發(fā)生故障，B 庫(kù)成為主庫(kù)負(fù)責(zé)讀寫(xiě)，修復(fù)故障后，A 成為從庫(kù)，主庫(kù) B 同步數(shù)據(jù)到從庫(kù) A。
一臺(tái)主庫(kù)多臺(tái)從庫(kù)，A 為主庫(kù)，負(fù)責(zé)讀寫(xiě)，B、C、D為從庫(kù)，負(fù)責(zé)讀數(shù)據(jù)。
如果 A 庫(kù)發(fā)生故障，B 庫(kù)成為主庫(kù)負(fù)責(zé)讀寫(xiě)，C、D負(fù)責(zé)讀，修復(fù)故障后，A 也成為從庫(kù)，主庫(kù) B 同步數(shù)據(jù)到從庫(kù) A。
用 pt-table-checksum 時(shí)，會(huì)不會(huì)影響業(yè)務(wù)性能？
實(shí)驗(yàn)
實(shí)驗(yàn)開(kāi)始前，給大家分享一個(gè)小經(jīng)驗(yàn)：任何性能評(píng)估，不要相信別人的評(píng)測(cè)結(jié)果，要在自己的環(huán)境上測(cè)試，并（大概）知曉原理。
我們先建一對(duì)主從：
然后用 mysqlslap跑一個(gè)持續(xù)的壓力：
開(kāi)另外一個(gè)會(huì)話，將 master 上的 general log 打開(kāi)：
然后通過(guò) pt-table-checksum 進(jìn)行一次比較：
查看 master 的 general log，由于 mysqlslap 的影響，general log 中有很多內(nèi)容，我們找到與 pt-table-checksum 相關(guān)的線程：
將該線程的操作單獨(dú)列出來(lái)：
操作比較多，我們一點(diǎn)一點(diǎn)來(lái)說(shuō)明：
這里工具調(diào)小了 innodb 鎖等待時(shí)間。使得之后的操作，只要在 innodb 上稍微有鎖等待，就會(huì)馬上放棄操作，對(duì)業(yè)務(wù)影響很小。
另外工具調(diào)小了 wait_timeout 時(shí)間，倒是沒(méi)有特別的作用。
工具將隔離級(jí)別調(diào)整為了 RR 級(jí)別，事務(wù)的維護(hù)代價(jià)會(huì)比 RC 要高，不過(guò)后面我們會(huì)看到工具使用的每個(gè)事務(wù)都很小，加上之前提到 innodb 鎖等待時(shí)間調(diào)到很小，對(duì)線上業(yè)務(wù)產(chǎn)生的成本比較小。
RR 級(jí)別是數(shù)據(jù)對(duì)比的基本要求。
工具通過(guò)一系列操作，了解表的概況。工具是一個(gè)數(shù)據(jù)塊一個(gè)數(shù)據(jù)塊進(jìn)行校驗(yàn)，這里獲取了第一個(gè)數(shù)據(jù)塊的下邊界。
接下來(lái)工具獲取了下一個(gè)數(shù)據(jù)塊的下邊界，每個(gè) SQL前都會(huì) EXPLAIN 一下，看一下執(zhí)行成本，非常小心翼翼。
之后工具獲取了一個(gè)數(shù)據(jù)塊的 checksum，這個(gè)數(shù)據(jù)塊不大，如果跟業(yè)務(wù)流量有沖突，會(huì)馬上出發(fā) innodb 的鎖超時(shí)，立刻退讓。
以上是 pt-table-checksum 的一些設(shè)計(jì)，可以看到這幾處都是精心維護(hù)了業(yè)務(wù)流量不受影響。
工具還設(shè)計(jì)了其他的一些機(jī)制保障業(yè)務(wù)流量，比如參數(shù) --max-load 和 --pause-file 等，還有精心設(shè)計(jì)的數(shù)據(jù)塊劃分方法，索引選擇方法等。大家根據(jù)自己的情況配合使用即可達(dá)到很好的效果。
總結(jié)
本期我們介紹了簡(jiǎn)單分析 pt-table-checksum 是否會(huì)影響業(yè)務(wù)流量，坊間會(huì)流傳工具的各種參數(shù)建議或者不建議使用，算命的情況比較多，大家都可以用簡(jiǎn)單的實(shí)驗(yàn)來(lái)分析其中機(jī)制。
還是那個(gè)觀點(diǎn)，性能測(cè)試不能相信道聽(tīng)途說(shuō)，得通過(guò)實(shí)驗(yàn)去分析。
其實(shí)就是主要看 Slave_IO_Running 和 Slave_SQL_Running 兩個(gè)線程的狀態(tài)。
重慶分公司
重慶分公司
