mysql 主從同步原理

標籤：style   使用   io   strong   檔案   ar   資料   問題   div   

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 將會更加受人歡迎，可實施性也會更大。

mysql 主從同步原理