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

?

?

轉自： http://machael.blog.51cto.com/829462/239112