MySQL 基礎技術(四)—— MySQL 如何保證高可用杀狡?

之前,有一年多的工作客戶端領域的工作經(jīng)驗贰镣。
后來呜象,也在字節(jié)做了一年多的后端業(yè)務。
現(xiàn)在希望做一些 MySQL 總結碑隆,豐富一下自己在后端領域的積累恭陡。
目錄如下:
MySQL 基礎技術(一) —— MySQL 是如何查詢的?
MySQL 基礎技術(二) —— MySQL 是如何更新的上煤?
MySQL 基礎技術(三)—— MySQL 如何保證數(shù)據(jù)不丟失休玩?
MySQL 基礎技術(四)—— MySQL 如何保證高可用?


一、引子

上一篇文章哥捕,我們講述了:《MySQL 如何保證數(shù)據(jù)不丟失牧抽?》,介紹了 binlogredo log 的工作流程遥赚。
那么扬舒,MySQL 怎么保證高可用呢?
為了提高 MySQL 的讀寫性能凫佛,我們往往采用 MySQL 一主多從的方案讲坎。
即一個主庫(主要負責寫),多個從庫(只負責讀)愧薛。
因為單實例有性能瓶頸晨炕,多從庫能優(yōu)先解決 MySQL 的讀負載壓力。

二毫炉、主從同步

主從同步(簡化)

原理:

MySQL 設計成一主多從模式瓮栗。

簡單來說,主要分為三步:

  • 第一步:所有增刪改的 DML 語句都在 master 節(jié)點的示例上完成瞄勾。
  • 第二步:將處理完成的 binlog 日志傳輸?shù)礁鱾€ slave 節(jié)點费奸。
  • 第三步:多個 slave 節(jié)點處理 binlog,從而保持主從一致进陡。

詳細來說愿阐,

主從同步(詳細)

MasterSlave 之間會維護一個長連接,專門用來同步binlog趾疚。

創(chuàng)建從庫的過程:

  1. Slave 機器上缨历,通過 change master 命令,設置主庫的 IP糙麦、端口號辛孵、用戶名、密碼赡磅,以及binlog 從哪里開始獲取等信息(具體binlog文件名 + 文件偏移量)觉吭。
  2. Slave 機器上,執(zhí)行start slave命令仆邓,啟動 io_threadsql_thread 線程。
    其中 io_thread 用于接收主庫的 binlog伴鳖,sql_thread 用于處理主庫的 binlog节值。
  3. Slave 開始嘗試連接 MasterMaster 校驗完用戶名密碼后榜聂,dump_thread 根據(jù) Slave 設置的 binlog 文件和偏移量搞疗,開始讀取 binlog 發(fā)送給 Slave
  4. Slaveio_thread 將接收到的 binlog 寫到 relay log (中轉日志)须肆。
  5. sql_thread 讀取中轉日志匿乃,執(zhí)行對應SQL桩皿,同步完成。

問題:

1. 主從延遲

即“同步延遲”幢炸。
表示同一個事務下泄隔,主庫執(zhí)行完成到備庫執(zhí)行完成的時間差值。

主從延遲時間

時間線:

  1. Master 執(zhí)行一個事務宛徊,成功寫入binlog —— 這個時刻佛嬉,我們記為 T1
  2. Slaveio_thread 接收到binlog —— 這個時刻闸天,我們記為 T2暖呕。
  3. Slave執(zhí)行完這個事務“—— 這個時刻湾揽,我們記為 T3

所謂主從延遲笼吟,就是 T3-T1 的時間库物。

如果在這段時間里,在從庫上查詢主庫剛插入/修改的數(shù)據(jù)赞厕,會出現(xiàn)主從不一致的現(xiàn)象艳狐。
這時,一些對可靠性要求比較高的業(yè)務場景里皿桑,就會出現(xiàn)錯誤毫目。
我們可以在從庫上執(zhí)行:

show slave status;

其中,seconds_behind_master 就是從庫延遲的時間(T3-T1

主從延遲的根本原因是:從庫消費中轉日志(relay log)的速度比主庫生產(chǎn) binlog 的速度慢诲侮。

2. 主從切換

在實際場景下镀虐,可能會遇到主庫所在機器異常、掉電沟绪、或者機房升級等等刮便。
這就會涉及到“主庫”與“從庫”之間的切換問題。
由于主從延遲的存在绽慈,在主從切換的時候恨旱,就會有不同的策略。

主從切換

可靠性優(yōu)先策略(推薦):

  1. 查詢 slaveseconds_behind_master坝疼,如果小于預定的某個值(比如3秒)搜贤,就下一步。
    否則就一直輪訓钝凶,直到出現(xiàn)滿足條件的Slave仪芒。(選未來主庫)
  2. masterreadonly = true,降為從庫。
  3. 查詢該 slave(未來主庫) 的 seconds_behind_master 值變成 0掂名。(即無主從延遲)
  4. 將該 slave (未來主庫)的狀態(tài)變成讀寫据沈。readonly = false,升成主庫饺蔑。
  5. 將請求流量切到新主庫锌介。
  • 優(yōu)點:可靠性高,數(shù)據(jù)可靠膀钠。
  • 缺點:會有一小段不可用的時間掏湾。

因此,得選擇 seconds_behond_master 比較短的 slavemaster肿嘲。

可用性優(yōu)先策略:

  1. 直接將 slave (未來主庫)的狀態(tài)變成讀寫融击。readonly = false,升成主庫雳窟。
  2. 將請求流量切到新主庫尊浪。
  3. 將老主庫的 readonly = true,降為從庫封救。
  • 優(yōu)點:可用性高拇涤,沒有真空期。
  • 缺點:可能會出現(xiàn)數(shù)據(jù)不一致的情況誉结。

三鹅士、如何保證高可用

MySQL 如果要保證高可用,就要滿足三個條件惩坑。

  1. 數(shù)據(jù)不丟失掉盅。(雙1策略)
  2. 主從最終一致性。(主庫所有binlog以舒,備庫都執(zhí)行了)
  3. 無主從延遲趾痘。

主從延遲的來源:

1. Slave 所在機器性能問題。(部署在同一機器上)

我就遇到過這種 case:
我們的數(shù)據(jù)庫和飛書的數(shù)據(jù)庫部署在同一個機器上蔓钟,
他們在大量的做一些DML操作永票,刪除/歸檔很多老數(shù)據(jù)。
導致于我們的Slave資源被一直搶占滥沫,進而出現(xiàn)主從延遲侣集。

解決思路:

  1. 如果成本允許,按服務兰绣,分開獨立部署肚吏。

2. Slave 壓力大,查詢耗費了大量CPU資源狭魂,影響了同步速度。

這種也比較常見,表/索引設計不合理雌澄、或者有臨時任務在拖庫斋泄,導致慢慢查詢,耗費了大量CPU資源镐牺。導致 io_thread炫掐、sql_thread 搶占不到資源進而同步緩慢。

解決思路:
1.優(yōu)化表設計睬涧、索引設計募胃。解決慢 SQL 問題。
2.增加從庫畦浓,分擔現(xiàn)有從庫的壓力痹束。
3.對于一些臨時/定時任務:可用 Binlog -> Hadoop。轉移讓另外一個系統(tǒng)來提供查詢能力讶请。

3. 大事務

這種也比較好理解祷嘶,主庫上執(zhí)行一個大事務花了n分鐘,那么大概率就會導致從庫延遲n分鐘夺溢。
比如论巍,磁盤空間快滿了,需要歸檔一些歷史數(shù)據(jù)风响,需要一次性刪除大量歷史數(shù)據(jù)嘉汰。這時候和就會出現(xiàn)主從延遲。

解決思路:
1.業(yè)務允許的話状勤,控制每個事務的數(shù)據(jù)量鞋怀,分成多次操作。

參考與致謝:
1.《MySQL實戰(zhàn)45講》(林曉斌老師)

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末荧降,一起剝皮案震驚了整個濱河市接箫,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌朵诫,老刑警劉巖辛友,帶你破解...
    沈念sama閱讀 222,681評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異剪返,居然都是意外死亡废累,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,205評論 3 399
  • 文/潘曉璐 我一進店門脱盲,熙熙樓的掌柜王于貴愁眉苦臉地迎上來邑滨,“玉大人,你說我怎么就攤上這事钱反∫纯矗” “怎么了匣距?”我有些...
    開封第一講書人閱讀 169,421評論 0 362
  • 文/不壞的土叔 我叫張陵,是天一觀的道長哎壳。 經(jīng)常有香客問我毅待,道長,這世上最難降的妖魔是什么归榕? 我笑而不...
    開封第一講書人閱讀 60,114評論 1 300
  • 正文 為了忘掉前任尸红,我火速辦了婚禮,結果婚禮上刹泄,老公的妹妹穿的比我還像新娘外里。我一直安慰自己,他們只是感情好特石,可當我...
    茶點故事閱讀 69,116評論 6 398
  • 文/花漫 我一把揭開白布盅蝗。 她就那樣靜靜地躺著,像睡著了一般县匠。 火紅的嫁衣襯著肌膚如雪风科。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,713評論 1 312
  • 那天乞旦,我揣著相機與錄音贼穆,去河邊找鬼。 笑死兰粉,一個胖子當著我的面吹牛故痊,可吹牛的內容都是我干的。 我是一名探鬼主播玖姑,決...
    沈念sama閱讀 41,170評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼愕秫,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了焰络?” 一聲冷哼從身側響起戴甩,我...
    開封第一講書人閱讀 40,116評論 0 277
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎闪彼,沒想到半個月后甜孤,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,651評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡畏腕,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,714評論 3 342
  • 正文 我和宋清朗相戀三年缴川,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片描馅。...
    茶點故事閱讀 40,865評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡把夸,死狀恐怖,靈堂內的尸體忽然破棺而出铭污,到底是詐尸還是另有隱情恋日,我是刑警寧澤膀篮,帶...
    沈念sama閱讀 36,527評論 5 351
  • 正文 年R本政府宣布,位于F島的核電站谚鄙,受9級特大地震影響各拷,放射性物質發(fā)生泄漏。R本人自食惡果不足惜闷营,卻給世界環(huán)境...
    茶點故事閱讀 42,211評論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望知市。 院中可真熱鬧傻盟,春花似錦、人聲如沸嫂丙。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,699評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽跟啤。三九已至诽表,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間隅肥,已是汗流浹背竿奏。 一陣腳步聲響...
    開封第一講書人閱讀 33,814評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留腥放,地道東北人泛啸。 一個月前我還...
    沈念sama閱讀 49,299評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像秃症,于是被迫代替她去往敵國和親候址。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,870評論 2 361