這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)MySQL主從同步的原理是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

為巴彥等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及巴彥網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站制作、成都網(wǎng)站設(shè)計、巴彥網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

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

上述就是小編為大家分享的MySQL主從同步的原理是什么了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)頁題目：MySQL主從同步的原理是什么-創(chuàng)新互聯(lián)
新聞來源：http://aaarwkj.com/article16/cojidg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、服務(wù)器托管、App開發(fā)、網(wǎng)站建設(shè)、建站公司、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)