一、復制機制的實現原理

從高層來看，復制分成三步：
(1)????master 將改變記錄到二進制日志 (binary?log) 中（這些記錄叫做二進制日志事件， binary?log?events ）；
(2)????slave 將 master 的 binary?log?events 拷貝到它的中繼日志 (relay?log) ；
(3)????slave 重做中繼日志中的事件，將改變反映它自己的數據。

?

二、復制實現級別

1.?Row

日志中會記錄成每一行數據被修改的形式，然后在?slave?端再對相同的數據進行修改。

優點：在?row?模式下，bin-log?中可以不記錄執行的?SQL?語句的上下文相關的信息，僅僅只需要記錄哪一條記錄被修改了，修改成什么樣了。所以?row?的日志內容會非常清楚的記錄下每一行數據修改的細節，非常容易理解。而且不會出現某些特定情況下的存儲過程或?function?，以及?trigger?的調用和觸發無法被正確復制的問題。

缺點：在?row?模式下，所有的執行的語句當記錄到日志中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容

2.?Statement

每一條會修改數據的?SQL?都會記錄到?master?的?bin-log?中。slave?在復制的時候?SQL?進程會解析成和原來?master?端執行過的相同的?SQL?再次執行。

優點：在?statement?模式下，首先就是解決了?row?模式的缺點，不需要記錄每一行數據的變化，減少了?bin-log?日志量，節省?I/O?以及存儲資源，提高性能。因為他只需要記錄在?master?上所執行的語句的細節，以及執行語句時候的上下文的信息。

缺點：在?statement?模式下，由于他是記錄的執行語句，所以，為了讓這些語句在?slave?端也能正確執行，那么他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證所有語句在?slave?端杯執行的時候能夠得到和在?master?端執行時候相同的結果。復制容易問題

3.?mixed

在?Mixed?模式下，MySQL?會根據執行的每一條具體的?SQL?語句來區分對待記錄的日志形式，也就是在?statement?和?row?之間選擇一種。新版本中的?statment?還是和以前一樣，僅僅記錄執行的語句。而新版本的?MySQL?中對?row?模式也被做了優化，并不是所有的修改都會以?row?模式來記錄，比如遇到表結構變更的時候就會以?statement?模式來記錄，如果?SQL?語句確實就是?update?或者?delete?等修改數據的語句，那么還是會記錄所有行的變更。

三、復制常用架構

1、單一 master 和多 slave
由一個 master 和一個 slave 組成復制系統是最簡單的情況。 Slave 之間并不相互通信，只能與 master 進行通信。如下：

如果寫操作較少，而讀操作很時，可以采取這種結構。你可以將讀操作分布到其它的 slave ，從而減小 master 的壓力。但是，當 slave 增加到一定數量時， slave 對 master 的負載以及網絡帶寬都會成為一個嚴重的問題。
這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：
(1)???? 不同的 slave 扮演不同的作用 ( 例如使用不同的索引，或者不同的存儲引擎 ) ；
(2)???? 用一個 slave 作為備用 master ，只進行復制；
(3)???? 用一個遠程的 slave ，用于災難恢復；

?

2、Dual?Master?(Master-Master)

Master-Master 復制的兩臺服務器，既是 master ，又是另一臺服務器的 slave

?