Replication 線程
Mysql的 Replication 是一個異步的復制過程,從一個 Mysql instace(我們稱之為 Master)復制到另一個 Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實現整個復制過程主要由三個線程來完成,其中兩個線程(Sql線程和IO線程)在 Slave 端,另外一個線程(IO線程)在 Master 端。
要實現 MySQL 的 Replication ,首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否則無法實現。因為整個復制過程實際上就是Slave從Master端獲取該日志然后再在自己身上完全 順序的執行日志中所記錄的各種操作。打開 MySQL 的 Binary Log 可以通過在啟動 MySQL Server 的過程中使用 “—log-bin” 參數選項,或者在 my.cnf 配置文件中的 mysqld 參數組([mysqld]標識后的參數部分)增加 “log-bin” 參數項。
MySQL 復制的基本過程如下:
1. Slave 上面的IO線程連接上 Master,并請求從指定日志文件的指定位置(或者從最開始的日志)之后的日志內容;
2. Master 接收到來自 Slave 的 IO 線程的請求后,通過負責復制的 IO 線程根據請求信息讀取指定日志指定位置之后的日志信息,返回給 Slave 端的 IO 線程。返回信息中除了日志所包含的信息之外,還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 Binary Log 中的位置;
3. Slave 的 IO 線程接收到信息后,將接收到的日志內容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,并將讀取到的Master端的bin-log的文件名和位置記錄到master- info文件中,以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log的哪個位置開始往后的日志內容,請發給我”
4. Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容后,會馬上解析該 Log 文件中的內容成為在 Master 端真實執行時候的那些可執行的 Query 語句,并在自身執行這些 Query。這樣,實際上就是在 Master 端和 Slave 端執行了同樣的 Query,所以兩端的數據是完全一樣的。
實際上,在老版本中,MySQL 的復制實現在 Slave 端并不是由 SQL 線程和 IO 線程這兩個線程共同協作而完成的,而是由單獨的一個線程來完成所有的工作。但是 MySQL 的工程師們很快發現,這樣做存在很大的風險和性能問題,主要如下:
首先,如果通過一個單一的線程來獨立實現這個工作的話,就使復制 Master 端的,Binary Log日志,以及解析這些日志,然后再在自身執行的這個過程成為一個串行的過程,性能自然會受到較大的限制,這種架構下的 Replication 的延遲自然就比較長了。
其次,Slave 端的這個復制線程從 Master 端獲取 Binary Log 過來之后,需要接著解析這些內容,還原成 Master 端所執行的原始 Query,然后在自身執行。在這個過程中,Master端很可能又已經產生了大量的變化并生成了大量的 Binary Log 信息。如果在這個階段 Master 端的存儲系統出現了無法修復的故障,那么在這個階段所產生的所有變更都將永遠的丟失,無法再找回來。這種潛在風險在Slave 端壓力比較大的時候尤其突出,因為如果 Slave 壓力比較大,解析日志以及應用這些日志所花費的時間自然就會更長一些,可能丟失的數據也就會更多。
所以,在后期的改造中,新版本的 MySQL 為了盡量減小這個風險,并提高復制的性能,將 Slave 端的復制改為兩個線程來完成,也就是前面所提到的 SQL 線程和 IO 線程。最早提出這個改進方案的是Yahoo!的一位工程師“Jeremy Zawodny”。通過這樣的改造,這樣既在很大程度上解決了性能問題,縮短了異步的延時時間,同時也減少了潛在的數據丟失量。
當然,即使是換成了現在這樣兩個線程來協作處理之后,同樣也還是存在 Slave 數據延時以及數據丟失的可能性的,畢竟這個復制是異步的。只要數據的更改不是在一個事務中,這些問題都是存在的。
如果要完全避免這些問題,就只能用 MySQL 的 Cluster 來解決了。不過 MySQL的 Cluster 知道筆者寫這部分內容的時候,仍然還是一個內存數 據庫的解決方案,也就是需要將所有數據包括索引全部都 Load 到內存中,這樣就對內存的要求就非常大的大,對于一般的大眾化應用來說可實施性并不是太大。當然,在之前與 MySQL 的 CTO David 交流的時候得知,MySQL 現在正在不斷改進其 Cluster 的實現,其中非常大的一個改動就是允許數據不用全部 Load 到內存中,而僅僅只是索引全部 Load 到內存中,我想信在完成該項改造之后的 MySQL Cluster 將會更加受人歡迎,可實施性也會更大。
?
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
