面試官:咱們來(lái)聊一聊mysql主從延遲

EasonTyler 發(fā)布于2021-11-17 17:08 / 3764人閱讀

摘要：編輯器編輯器背景編輯器前段時(shí)間遇到一個(gè)線上問題，后來(lái)排查好久發(fā)現(xiàn)是因?yàn)橹鲝耐窖舆t導(dǎo)致的，所以今天寫一篇文章總結(jié)一下這個(gè)問題希望對(duì)你有用。編輯器幾句嘮叨編輯器大家好，我是小飯，一枚后端工程師。

背景

前段時(shí)間遇到一個(gè)線上問題，后來(lái)排查好久發(fā)現(xiàn)是因?yàn)橹鲝耐窖舆t導(dǎo)致的，所以今天寫一篇文章總結(jié)一下這個(gè)問題希望對(duì)你有用。如果覺得還不錯(cuò),記得加個(gè)關(guān)注點(diǎn)個(gè)贊哦

思維導(dǎo)圖

常見的主從架構(gòu)

隨著日益增長(zhǎng)的訪問量，單臺(tái)數(shù)據(jù)庫(kù)的能力已經(jīng)捉襟見肘。因此采用主庫(kù)寫數(shù)據(jù)，從庫(kù)讀數(shù)據(jù)這種將讀寫分離開的主從架構(gòu)便隨之衍生了出來(lái)。

一主一從

一主多從

一主一從和一主多從是最常見的主從架構(gòu)，實(shí)施起來(lái)簡(jiǎn)單并且有效，不僅可以實(shí)現(xiàn)高可用，還能讀寫分離，進(jìn)而提升集群的并發(fā)能力。

多主一從

雙主復(fù)制

級(jí)聯(lián)復(fù)制

主從同步原理

想要了解主從同步原理，首先得記住兩個(gè)很重要的日志文件

binlog（二進(jìn)制日志文件）
relay log（中繼日志文件）

主從同步過程

從庫(kù)生成兩個(gè)線程，一個(gè)I/O線程，一個(gè)SQL線程；
i/o線程去請(qǐng)求主庫(kù) 的binlog，并將得到的binlog日志寫到relay log（中繼日志）文件中；
主庫(kù)會(huì)生成一個(gè) log dump 線程，用來(lái)給從庫(kù) i/o線程傳binlog
SQL 線程，會(huì)讀取relay log文件中的日志，并解析成具體操作，來(lái)實(shí)現(xiàn)主從的操作一致，而最終數(shù)據(jù)一致；

如何判斷主從是否延時(shí)

通過監(jiān)控 show slave status 命令輸出的Seconds_Behind_Master參數(shù)的值來(lái)判斷：

NULL，表示io_thread或是sql_thread有任何一個(gè)發(fā)生故障；
0，該值為零，表示主從復(fù)制良好；
正值，表示主從已經(jīng)出現(xiàn)延時(shí)，數(shù)字越大表示從庫(kù)延遲越嚴(yán)重。

主從延遲原因

隨機(jī)重放

MySQL的主從復(fù)制都是單線程的操作，主庫(kù)對(duì)所有DDL和DML產(chǎn)生的日志寫進(jìn)binlog，由于binlog是順序?qū)?，所以效率很高。Slave的SQL Thread線程將主庫(kù)的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是隨機(jī)的，不是順序的，成本高很多。所以SQL Thread線程的速度趕不上主庫(kù)學(xué)binlog的速度，就會(huì)產(chǎn)生主從延遲

鎖等待

另一方面，由于SQL Thread也是單線程的，當(dāng)主庫(kù)的并發(fā)較高時(shí)，產(chǎn)生的DML數(shù)量超過slave的SQL Thread所能處理的速度，或者當(dāng)slave中有大型query語(yǔ)句產(chǎn)生了鎖等待那么延時(shí)就產(chǎn)生了。

主從延遲解決辦法

并行復(fù)制

既然 SQL 單線程進(jìn)行重放時(shí)速度有限，那么能不能采用多線程的方式來(lái)進(jìn)行重放呢？MySQL 5.6 版本后，提供了一種并行復(fù)制的方式，通過將 SQL 線程轉(zhuǎn)換為多個(gè) work 線程來(lái)進(jìn)行重放，這樣就解決了主從延遲的問題