Master/Slave
Master: write/read，寫操作都在主節點上操作
Slaves: read，讀操作都是從節點這邊發出
爲什麼要複製？
冗餘：promte（提升爲主），異地災備，可以通過人工或者工具程序（MHA）實現
擴展：轉移一部分“讀”請求；
支援安全的備份操作；
測試需要；
主/從架構實現：
在主節點上啓用二進制日誌，從節點啓動連接線程，請求主節點把這個事件發給自己一份，從節點上有一個線程叫IO Thread,主節點上啓用dump thread，IO Thread從節點將接受到的日誌存儲到中繼日誌，從服務器上的SQL THread負責從中繼日誌裏生成一份數據。這樣的數據同步方式是異步。主服務器負責寫操作，從服務器負責讀操作。
主從有可能導致主從數據不一致。如主服務多線程進程，從服務區是單線程進程，有可能導致主從數據不一致，從服務器的數據可能會落後於主服務器，這個問題是不可避免的，只能儘早發現，將不正確的數據手動更改，如果數據差別很大，手動恢復很難，可以在主服務器上做備份，把數據直接回復到從服務器上。
主服務器存到二進制log，存到從服務器上是異步操作的。傳輸是單向的。但是這裏有個問題，如果寫操作超出主服務器的性能，解決方法，使用雙主模型
主從複製的三種形式：同步複製，異步複製，半同步複製
同步複製：
雙主模型：寫操作都在本地寫，同步給另一個節點，放到relay中。
主服務器都要啓動中繼日誌和二進制日誌，所有發給本節點的寫操作，都要記錄到二進制日誌中，並通過dump thread發給對端主服務器，對端主服務器通過io thread將收到的數據存儲到中繼日誌中，並依靠sql thread實現重放。主節點實現了冗餘。每個節點都可以讀和寫操作。這種操作可以降低讀請求，每個服務器負載一半的請求，但是寫操作的請求數量是一樣的，因爲，雙主的服務器都要寫入一份數據。
利用中間件的讀寫分離器實現請求讀寫分離，中間件可以利用keepalive實現冗餘。但是有了雙主模型，就不需要讀寫分離，只需要用haproxy或者nginx或者lvs來實現請求的四層調度將請求調度到不同服務器上即可。
mysql主從複製弊端可能運行一段時間後，根據業務邏輯的不一樣，可能導致主從數據不一致，導致得到的數據不一致。該情況在數據要求強一致的情況下是不允許存在的。
在主服務器上，操作是多線程並行的，但是記錄到二進制文件中是串行記錄，從服務器是單線程運行獲取數據，這樣導致從服務器拉取數據的速度落後於主服務器，導致了數據的差異，長此以往會導致數據嚴重不一致。如果這裏設置讀寫分離，可能導致從服務器上讀出的數據是錯誤的。雙主模型同樣有這個問題。主從數據不一致，建議解決辦法是手動修改數據。如果數據差別太大，將從服務器關閉，在主服務器上做備份，恢復到從服務器上。
異步複製：
一主多從；
一從一主；
級聯複製；一主複製給一從，同時，這個從服務器又是其他服務器的主，其他從服務器到這個中繼服務器複製數據，級聯的作用是降低主服務器的壓力。中間的這個從服務器要啓用二進制日誌和中繼日誌，同時，中間這臺從服務器僅起到過渡的作用，不需要保存數據，因此將block hole引擎用於這個中間從服務器上，使得不會產生數據保存，但是中繼日誌和二進制日誌都有正常保存，起到過渡的效果。
循環複製；多主模式下，採用循環複製，但是鏈條更長，可能導致數據落後嚴重。
雙主複製；
半同步複製：
一從多主模型：每個主服務器提供不同的數據庫，master只保證slaves中的一個操作成功，就返回，其他slave不管。這個功能，是由google爲MYSQL引入的。