Mysql主從同步架構圖和原理

架構圖Replication原理   
Mysql 的 Replication 是一個非同步複製過程，從一個MySQL節點（稱之為Master）複製到另一個MySQL節點（稱之Slave）。在 Master 與 Slave 之間的實現整個複製過程主要由三個線程來完成，其中兩個線程（SQL 線程和 I/O 線程）在 Slave 端，另外一個線程（I/O 線程）在
Master 端。 
  
要實現 MySQL 的 Replication ，首先必須開啟 Master 端的 Binary Log，因為整個複製過程實際上就是 Slave 從 Master 端擷取該日誌然後再在自己身上完全順序的執行日誌中所記錄的各種操作。 
  
看上去MySQL的Replication原理非常簡單，總結一下： 
     * 每個從僅可以設定一個主。 
    * 主在執行sql之後，記錄二進位log檔案（bin-log）。 
    * 從串連主，並從主擷取binlog，存於本地relay-log，並從上次記住的位置起執行sql，一旦遇到錯誤則停止同步。 
   
從這幾條Replication原理來看，可以有這些推論： 
     * 主從間的資料庫不是即時同步，就算網路連接正常，也存在瞬間，主從資料不一致。 
    * 如果主從的網路斷開，從會在網路正常後，批量同步。 
    * 如果對從進行修改資料，那麼很可能從在執行主的bin-log時出現錯誤而停止同步，這個是很危險的操作。所以一般情況下，非常小心的修改從上的資料。 
    * 一個衍生的配置是雙主，互為主從配置，只要雙方的修改不衝突，可以工作良好。 
    * 如果需要多主的話，可以用環形配置，這樣任意一個節點的修改都可以同步到所有節點。 
   
主從設定 
  
因為原理比較簡單，所以Replication從MySQL 3就支援，並在所有平台下可以工作，多個MySQL節點甚至可以不同平台，不同版本，不同區域網路。做Replication配置包括使用者和my.ini（linux下為my.cnf）兩處設定。 
  
首先在主MySQL節點上，為slave建立一個使用者： 
  
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'192.168.1.10' IDENTIFIED BY 'slave'; 
  
實際上，為支援主從動態同步，或者手動切換，一般都是在所有主從節點上建立好這個使用者。然後就是MySQL本身的配置了，這需要修改my.cnf或者my.ini檔案。在mysqld這一節下面增加： 
  
server-id=1    
auto-increment-increment=2     
auto-increment-offset=1     
log-bin     
binlog-do-db=mstest     
binlog_format=mixed 
  
master-host=192.168.1.62    
master-user=slave     
master-password=slave     
replicate-do-db=mstest 
  
上面這兩段設定，前一段是為主而設定，後一段是為從設定的。也就是說在兩個MySQL節點上，各加一段就好。binlog-do-db和 replicate-do-db就是設定相應的需要做同步的資料庫了，auto-increment-increment和auto- increment-offset是為了支援雙主而設定的（參考下一節），在只做主從的時候，也可以不設定。 
  
雙主的設定 
  
從原理論來看MySQL也支援雙主的設定，即兩個MySQL節點互為主備，不過雖然理論上，雙主只要資料不衝突就可以工作的很好，但實際情況中還 是很容發生資料衝突的，比如在同步完成之前，雙方都修改同一條記錄。因此在實際中，最好不要讓兩邊同時修改。即邏輯上仍按照主從的方式工作。但雙主的設定 仍然是有意義的，因為這樣做之後，切換主備會變的很簡單。因為在出現故障後，如果之前配置了雙主，則直接切換主備會很容易。 
  雙主在設定時，只需將上面的一段設定複製一份，分別寫入兩個MySQL節點的設定檔，但要修改相應的server-id，auto- increment-offset和master-host。auto-increment-offset就是為了讓雙主同時在一張表中進行添加操作時不 會出現id衝突，所以在兩個節點上auto-increment-offset設定為不同的值就好。 
另：不要忘了，在兩個節點上都為對方建立使用者。  應用程式層的負載平衡  本文只介紹了MySQL自身的Repilication配置，在上面的圖中也可以看出，有了Replication，還需要應用程式層（或者中介軟體）做一個負載平衡，這樣才能最大程度發揮MySQL
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，所以兩端的資料是完全一樣的。