MySQL主從復制原理探索

上一篇文章里面,講到了遇到mysql主從延遲的坑,對于這次的坑多說兩句,以前也看過這樣的例子,也知道不能夠寫完之后馬上更新,但是真正開發的時候還是沒有注意到這一點,道理大家都懂,但是還是會犯錯,只有等到自己親生體驗到該錯誤之后,才真正的掌握到該道理。

經歷過一次mysql主從延遲之后,就開始思考,主從復制是什么東西?它是怎么實現的呢?它的原理是什么?于是乎就開始查閱資料、文章,現將自己理解到的內容總結在此,加深印象。

為什么要做主從復制?

1、在業務復雜的系統中,有這么一個情景,有一句sql語句需要鎖表,導致暫時不能使用讀的服務,那么就很影響運行中的業務,使用主從復制,讓主庫負責寫,從庫負責讀,這樣,即使主庫出現了鎖表的情景,通過讀從庫也可以保證業務的正常運作。

2、做數據的熱備

3、架構的擴展。業務量越來越大,I/O訪問頻率過高,單機無法滿足,此時做多庫的存儲,降低磁盤I/O訪問的頻率,提高單個機器的I/O性能。

mysql主從復制的原理是什么?

binlog: binary log,主庫中保存所有更新事件日志的二進制文件。

主從復制的基礎是主庫記錄數據庫的所有變更記錄到binlog。binlog是數據庫服務器啟動的那一刻起,保存所有修改數據庫結構或內容的一個文件。

mysql主從復制是一個異步的復制過程,主庫發送更新事件到從庫,從庫讀取更新記錄,并執行更新記錄,使得從庫的內容與主庫保持一致。

在主庫里,只要有更新事件出現,就會被依次地寫入到binlog里面,之后會推到從庫中作為從庫進行復制的數據源。

binlog輸出線程。每當有從庫連接到主庫的時候,主庫都會創建一個線程然后發送binlog內容到從庫。
對于每一個即將發送給從庫的sql事件,binlog輸出線程會將其鎖住。一旦該事件被線程讀取完之后,該鎖會被釋放,即使在該事件完全發送到從庫的時候,該鎖也會被釋放。

在從庫里,當復制開始的時候,從庫就會創建兩個線程進行處理:

從庫I/O線程。當START SLAVE語句在從庫開始執行之后,從庫創建一個I/O線程,該線程連接到主庫并請求主庫發送binlog里面的更新記錄到從庫上。
從庫I/O線程讀取主庫的binlog輸出線程發送的更新并拷貝這些更新到本地文件,其中包括relay log文件。

從庫的SQL線程。從庫創建一個SQL線程,這個線程讀取從庫I/O線程寫到relay log的更新事件并執行。

可以知道,對于每一個主從復制的連接,都有三個線程。擁有多個從庫的主庫為每一個連接到主庫的從庫創建一個binlog輸出線程,每一個從庫都有它自己的I/O線程和SQL線程。

從庫通過創建兩個獨立的線程,使得在進行復制時,從庫的讀和寫進行了分離。因此,即使負責執行的線程運行較慢,負責讀取更新語句的線程并不會因此變得緩慢。比如說,如果從庫有一段時間沒運行了,當它在此啟動的時候,盡管它的SQL線程執行比較慢,它的I/O線程可以快速地從主庫里讀取所有的binlog內容。這樣一來,即使從庫在SQL線程執行完所有讀取到的語句前停止運行了,I/O線程也至少完全讀取了所有的內容,并將其安全地備份在從庫本地的relay log,隨時準備在從庫下一次啟動的時候執行語句。

查看主從復制的狀態

當主從復制正在進行中時,如果想查看從庫兩個線程運行狀態,可以通過執行在從庫里執行”show slave status\G”語句,以下的字段可以給你想要的信息:

Master_Log_File — 上一個從主庫拷貝過來的binlog文件
Read_Master_Log_Pos — 主庫的binlog文件被拷貝到從庫的relay log中的位置
Relay_Master_Log_File — SQL線程當前處理中的relay log文件
Exec_Master_Log_Pos — 當前binlog文件正在被執行的語句的位置

整個主從復制的流程可以通過以下圖示理解:

DB Replication
  • 步驟一:主庫db的更新事件(update、insert、delete)被寫到binlog
  • 步驟二:從庫發起連接,連接到主庫
  • 步驟三:此時主庫創建一個binlog dump thread,把binlog的內容發送到從庫
  • 步驟四:從庫啟動之后,創建一個I/O線程,讀取主庫傳過來的binlog內容并寫入到relay log
  • 步驟五:還會創建一個SQL線程,從relay log里面讀取內容,從Exec_Master_Log_Pos位置開始執行讀取到的更新事件,將更新內容寫入到slave的db
注:上面的解釋是解釋每一步做了什么,整個mysql主從復制是異步的,不是按照上面的步驟執行的。

其他

關于主從復制架構的搭建,可以參考網上更多的文檔,文筆有限,不做更多的介紹。

作為一名開發,這些基礎的mysql知識還是需要多多學習。

參考資料

What is MySQL Replication and How Does It Work?

Replication Implementation Details

原創文章,文筆有限,才疏學淺,文中若有不正之處,萬望告知。

如果本文對你有幫助,請點下推薦吧,謝謝_

更多精彩內容,請關注個人公眾號。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,001評論 6 537
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,786評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,986評論 0 381
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,204評論 1 315
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,964評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,354評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,410評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,554評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,106評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,918評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,093評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,648評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,342評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,755評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,009評論 1 289
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,839評論 3 395
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,107評論 2 375

推薦閱讀更多精彩內容