Mysql 主從復制原理

Mysql 主從復制原理

隨著網站業務的不斷發展，用戶量的不斷增加，數據量不斷地增長，數據庫的訪問量也相應的增長，到了一定的時間，網站首先出現的瓶頸就是在數據庫層 （這里沒有將緩存加入進來），這時候就需要對數據庫進行適當的拆分，比如說分庫或分表等，如果數據庫在分庫，分表后還是出現瓶頸，這時就好考慮數據庫讀寫 分離，尤其在讀多寫少的時候。

mysql中讀寫分離的方案就是主從復制，master服務器將更新的記錄到binary log中，mysql中這個叫二進制日志事件（binary log events）， slaver服務器將master中的binary log events 復制到自己的中繼日志（relay log）中，slave服務器將監聽中繼日志，將中繼日志的改變記錄到數據庫中。下圖描述了復制的過程：

其中，mysql支持大概3種類型的復制類型：

1.基于語句的復制，（也叫做邏輯復制，logical replication），優點是基于語句的復制的二進制日志可以很好的進行壓縮，而且日志的數據量也較小，缺點是基于語句的復制必須是串行化。

2.基于記錄的復制(Row-Based Replication)，在二進制日志中記錄下實際數據的改變,優點就是可以對任何語句都能正確工作，一些語句的效率更高,缺點就是二進制日志會很大，不能使用mysqlbinlog來查看二進制日志.

3.混合類型的復制,默認采用基于語句的復制，一旦發現基于語句的無法精確的復制時，就會采用基于行的復制.

復制能解決的一些問題：

1.數據分布 (Data distribution )

2.可以實現負載均衡(load balancing)，通常所說的讀寫分離

3.可以實現數據的備份(Backups)，但是不能當真正意義上數據備份來用

4.高可用性和容錯行(比如雙主模型中的互為主從能實現高可用)

但是，主從復制也帶來其他一系列其他問題，典型的就是主從不同步，導致主從不同步的原因是 ：服務器一般都是多核多線程，導致主節點可以同時執行多條讀寫操作，而記錄二進制日志則必須按順序有先后的記錄，從節點在一條一條復制過去，生成中繼日 志，再執行語句，這里就會出現復制延遲。其他問題就是寫入無法擴展，鎖表率上升等。

復制的體系結構有以下一些基本原則：

(1) 每個slave只能有一個master；

(2) 每個slave只能有一個唯一的服務器ID；

(3) 每個master可以有很多slave；

(4) 如果你設置log_slave_updates，slave可以是其它slave的master，從而擴散master的更新

Mysql復制常見的幾種模式：

1.一主多從

由一個master和一個slave組成復制系統是最簡單的情況。Slave之間并不相互通信，只能與master進行通信。主要用于讀壓力比較大的應用的數據庫端廉價擴展解決方案。

2.主主復制

Master-Master復制的兩臺服務器，既是master，又是另一臺服務器的slave。這樣，任何一方所做的變更，都會通過復制應用到另 外一方的數據庫中。在這種復制架構中，各自上運行的不是同一db，比如左邊的是db1,右邊的是db2，db1的從在右邊反之db2的從在左邊，兩者互為 主從，再輔助一些監控的服務還可以實現一定程度上的高可以用。

3.主動-被動模式(HA)

這種模式由master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在于其中只有一個節點在提供讀寫服務，另外一個節點時刻準備著，當主節點一旦故障馬上接替服務。比如通過corosync+pacemaker+drbd+mysql就可以提供這樣一組高可用服務，主備模式下再跟著slave服務器，也可以實現讀寫分離.

主從復制中容易出現的問題：

1.限制從服務器只讀，保證主從數據一致。

show global variables like ‘%read%‘

更改slave的全局服務器變量read_only為on

set global read_only on

從節點上授權只讀 set global read_only = 1;如果永久有效更改mysql的my.ini 或my.cnf，在[mysql] 中設置read_only = 1

2.保證主從復制時的事務安全

如果mysql比較繁忙它會把二進制日志緩存在內存中，不繁忙時才會把他寫到磁盤中，前提就是mysql對二進制日志事件數據會緩沖。在 master上設置如下參數 set global  sync_binlog = 1 事物一提交，就必須同步二進制日志，這樣會降低性能，但是數據非常重要的情況下。