mysql複製

1、複製機制的實現原理

從高層來看，複製分紅三步：
(1)    master將改變記錄到二進制日誌(binary log)中（這些記錄叫作二進制日誌事件，binary log events）；
(2)    slave將master的binary log events拷貝到它的中繼日誌(relay log)；
(3)    slave重作中繼日誌中的事件，將改變反映它本身的數據。

 

2、複製實現級別

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 等修改數據的語句，那麼仍是會記錄全部行的變動。

3、複製經常使用架構

一、單一master和多slave
由一個master和一個slave組成複製系統是最簡單的狀況。Slave之間並不相互通訊，只能與master進行通訊。以下：

若是寫操做較少，而讀操做很時，能夠採起這種結構。你能夠將讀操做分佈到其它的slave，從而減少master的壓力。可是，當slave增長到必定數量時，slave對master的負載以及網絡帶寬都會成爲一個嚴重的問題。
這種結構雖然簡單，可是，它卻很是靈活，足夠知足大多數應用需求。一些建議：
(1)    不一樣的slave扮演不一樣的做用(例如使用不一樣的索引，或者不一樣的存儲引擎)；
(2)    用一個slave做爲備用master，只進行復制；
(3)    用一個遠程的slave，用於災難恢復；

 

二、Dual Master (Master-Master)

Master-Master複製的兩臺服務器，既是master，又是另外一臺服務器的slave