mysql主從複制講解

1.1、複制解決的問題

資料複制技術有以下一些特點：

(1) 資料分布

(2) 負載平衡(load balancing)

(3) 備份

(4) 高可用性(high availability)和容錯

1.2、複制如何工作

從高層來看，複制分成三步：

(1) master将改變記錄到二進制日志(binary log)中（這些記錄叫做二進制日志事件，binary log events）；

(2) slave将master的binary log events拷貝到它的中繼日志(relay log)；

(3) slave重做中繼日志中的事件，将改變反映它自己的資料。

下圖描述了這一過程：

該過程的第一部分就是master記錄二進制日志。在每個事務更新資料完成之前，master在二日志記錄這些改變。MySQL将事務串行的寫入二進制日志，即使事務中的語句都是交叉執行的。在事件寫入二進制日志完成後，master通知存儲引擎送出事務。

下一步就是slave将master的binary log拷貝到它自己的中繼日志。首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接配接，然後開始binlog dump process。Binlog dump process從master的二進制日志中讀取事件，如果已經跟上master，它會睡眠并等待master産生新的事件。I/O線程将這些事件寫入中繼日志。

SQL slave thread處理該過程的最後一步。SQL線程從中繼日志讀取事件，更新slave的資料，使其與master中的資料一緻。隻要該線程與I/O線程保持一緻，中繼日志通常會位于OS的緩存中，是以中繼日志的開銷很小。

此外，在master中也有一個工作線程：和其它MySQL的連接配接一樣，slave在master中打開一個連接配接也會使得master開始一個線程。複制過程有一個很重要的限制——複制在slave上是串行化的，也就是說master上的并行更新操作不能在slave上并行操作。

MySQL開始複制是很簡單的過程，不過，根據特定的應用場景，都會在基本的步驟上有一些變化。最簡單的場景就是一個新安裝的master和slave，從高層來看，整個過程如下：

(1)在每個伺服器上建立一個複制帳号；

(2)配置master和slave；

(3)Slave連接配接master開始複制。

2.1、建立複制帳号

每個slave使用标準的MySQL使用者名和密碼連接配接master。進行複制操作的使用者會授予REPLICATION SLAVE權限。使用者名的密碼都會存儲在文本檔案master.info中。假如，你想建立repl使用者，如下：

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*

-> TO repl@’192.168.0.%’ IDENTIFIED BY ‘p4ssword’;

2.2、配置master

接下來對master進行配置，包括打開二進制日志，指定唯一的servr ID。例如，在配置檔案加入如下值：

[mysqld]

log-bin=mysql-bin

server-id=10

重新開機master，運作SHOW MASTER STATUS，輸出如下：

2.3、配置slave

Slave的配置與master類似，你同樣需要重新開機slave的MySQL。如下：

log_bin = mysql-bin

server_id = 2

relay_log = mysql-relay-bin

log_slave_updates = 1

read_only = 1

server_id是必須的，而且唯一。slave沒有必要開啟二進制日志，但是在一些情況下，必須設定，例如，如果slave為其它slave的master，必須設定bin_log。在這裡，我們開啟了二進制日志，而且顯示的命名(預設名稱為hostname，但是，如果hostname改變則會出現問題)。

relay_log配置中繼日志，log_slave_updates表示slave将複制事件寫進自己的二進制日志(後面會看到它的用處)。

有些人開啟了slave的二進制日志，卻沒有設定log_slave_updates，然後檢視slave的資料是否改變，這是一種錯誤的配置。是以，盡量使用read_only，它防止改變資料(除了特殊的線程)。但是，read_only并是很實用，特别是那些需要在slave上建立表的應用。

2.4、啟動slave

接下來就是讓slave連接配接master，并開始重做master二進制日志中的事件。你不應該用配置檔案進行該操作，而應該使用CHANGE MASTER TO語句，該語句可以完全取代對配置檔案的修改，而且它可以為slave指定不同的master，而不需要停止伺服器。如下：

mysql> CHANGE MASTER TO MASTER_HOST=’server1′,

-> MASTER_USER=’repl’,

-> MASTER_PASSWORD=’p4ssword’,

-> MASTER_LOG_FILE=’mysql-bin.000001′,

-> MASTER_LOG_POS=0;

MASTER_LOG_POS的值為0，因為它是日志的開始位置。然後，你可以用SHOW SLAVE STATUS語句檢視slave的設定是否正确：

Slave_IO_State, Slave_IO_Running, 和Slave_SQL_Running表明slave還沒有開始複制過程。日志的位置為4而不是0，這是因為0隻是日志檔案的開始位置，并不是日志位置。實際上，MySQL知道的第一個事件的位置是4。

為了開始複制，你可以運作：

mysql> START SLAVE;

運作SHOW SLAVE STATUS檢視輸出結果：

注意，slave的I/O和SQL線程都已經開始運作，而且Seconds_Behind_Master不再是NULL。日志的位置增加了，意味着一些事件被擷取并執行了。如果你在master上進行修改，你可以在slave上看到各種日志檔案的位置的變化，同樣，你也可以看到資料庫中資料的變化。

你可檢視master和slave上線程的狀态。在master上，你可以看到slave的I/O線程建立的連接配接：

行2為處理slave的I/O線程的連接配接。

在slave上運作該語句：

行1為I/O線程狀态，行2為SQL線程狀态。

2.5、從另一個master初始化slave

前面讨論的假設你是新安裝的master和slave，是以，slave與master有相同的資料。但是，大多數情況卻不是這樣的，例如，你的master可能已經運作很久了，而你想對新安裝的slave進行資料同步，甚至它沒有master的資料。

此時，有幾種方法可以使slave從另一個服務開始，例如，從master拷貝資料，從另一個slave克隆，從最近的備份開始一個slave。Slave與master同步時，需要三樣東西：

(1)master的某個時刻的資料快照；

(2)master目前的日志檔案、以及生成快照時的位元組偏移。這兩個值可以叫做日志檔案坐标(log file coordinate)，因為它們确定了一個二進制日志的位置，你可以用SHOW MASTER STATUS指令找到日志檔案的坐标；

(3)master的二進制日志檔案。

可以通過以下幾中方法來克隆一個slave：

(1) 冷拷貝(cold copy)

停止master，将master的檔案拷貝到slave；然後重新開機master。缺點很明顯。

(2) 熱拷貝(warm copy)

如果你僅使用MyISAM表，你可以使用mysqlhotcopy拷貝，即使伺服器正在運作。

(3) 使用mysqldump

使用mysqldump來得到一個資料快照可分為以下幾步：

<1>鎖表：如果你還沒有鎖表，你應該對表加鎖，防止其它連接配接修改資料庫，否則，你得到的資料可以是不一緻的。如下：

mysql> FLUSH TABLES WITH READ LOCK;

<2>在另一個連接配接用mysqldump建立一個你想進行複制的資料庫的轉儲：

shell> mysqldump –all-databases –lock-all-tables >dbdump.db

<3>對表釋放鎖。

mysql> UNLOCK TABLES;

已經讨論了關于複制的一些基本東西，下面深入讨論一下複制。

3.1、基于語句的複制(Statement-Based Replication)

MySQL 5.0及之前的版本僅支援基于語句的複制（也叫做邏輯複制，logical replication），這在資料庫并不常見。master記錄下改變資料的查詢，然後，slave從中繼日志中讀取事件，并執行它，這些SQL語句與master執行的語句一樣。

這種方式的優點就是實作簡單。此外，基于語句的複制的二進制日志可以很好的進行壓縮，而且日志的資料量也較小，占用帶寬少——例如，一個更新GB的資料的查詢僅需要幾十個位元組的二進制日志。而mysqlbinlog對于基于語句的日志處理十分友善。

但是，基于語句的複制并不是像它看起來那麼簡單，因為一些查詢語句依賴于master的特定條件，例如，master與slave可能有不同的時間。是以，MySQL的二進制日志的格式不僅僅是查詢語句，還包括一些中繼資料資訊，例如，目前的時間戳。即使如此，還是有一些語句，比如，CURRENT USER函數，不能正确的進行複制。此外，存儲過程和觸發器也是一個問題。

另外一個問題就是基于語句的複制必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。并不是所有的存儲引擎都支援基于語句的複制。

3.2、基于記錄的複制(Row-Based Replication)

MySQL增加基于記錄的複制，在二進制日志中記錄下實際資料的改變，這與其它一些DBMS的實作方式類似。這種方式有優點，也有缺點。優點就是可以對任何語句都能正确工作，一些語句的效率更高。主要的缺點就是二進制日志可能會很大，而且不直覺，是以，你不能使用mysqlbinlog來檢視二進制日志。

對于一些語句，基于記錄的複制能夠更有效的工作，如：

mysql> INSERT INTO summary_table(col1, col2, sum_col3)

-> SELECT col1, col2, sum(col3)

-> FROM enormous_table

-> GROUP BY col1, col2;

假設，隻有三種唯一的col1和col2的組合，但是，該查詢會掃描原表的許多行，卻僅傳回三條記錄。此時，基于記錄的複制效率更高。

另一方面，下面的語句，基于語句的複制更有效：

mysql> UPDATE enormous_table SET col1 = 0;

此時使用基于記錄的複制代價會非常高。由于兩種方式不能對所有情況都能很好的處理，是以，MySQL 5.1支援在基于語句的複制和基于記錄的複制之前動态交換。你可以通過設定session變量binlog_format來進行控制。

3.3、複制相關的檔案

除了二進制日志和中繼日志檔案外，還有其它一些與複制相關的檔案。如下：

(1)mysql-bin.index

伺服器一旦開啟二進制日志，會産生一個與二日志檔案同名，但是以.index結尾的檔案。它用于跟蹤磁盤上存在哪些二進制日志檔案。MySQL用它來定位二進制日志檔案。它的内容如下(我的機器上)：

(2)mysql-relay-bin.index

該檔案的功能與mysql-bin.index類似，但是它是針對中繼日志，而不是二進制日志。内容如下：

.\mysql-02-relay-bin.000017

.\mysql-02-relay-bin.000018

(3)master.info

儲存master的相關資訊。不要删除它，否則，slave重新開機後不能連接配接master。内容如下(我的機器上)：

I/O線程更新master.info檔案，内容如下(我的機器上)：

(4)relay-log.info

包含slave中目前二進制日志和中繼日志的資訊。

3.4、發送複制事件到其它slave

當設定log_slave_updates時，你可以讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行自己的二進制日志(binary log)，然後，它的slave可以擷取這些事件并執行它。如下：

3.5、複制過濾(Replication Filters)

複制過濾可以讓你隻複制伺服器中的一部分資料，有兩種複制過濾：在master上過濾二進制日志中的事件；在slave上過濾中繼日志中的事件。如下：

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

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

(2) 每個slave隻能有一個唯一的伺服器ID；

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

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

MySQL不支援多主伺服器複制(Multimaster Replication)——即一個slave可以有多個master。但是，通過一些簡單的組合，我們卻可以建立靈活而強大的複制體系結構。

4.1、單一master和多slave

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

如果寫操作較少，而讀操作很時，可以采取這種結構。你可以将讀操作分布到其它的slave，進而減小master的壓力。但是，當slave增加到一定數量時，slave對master的負載以及網絡帶寬都會成為一個嚴重的問題。

這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：

(1) 不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲引擎)；

(2) 用一個slave作為備用master，隻進行複制；

(3) 用一個遠端的slave，用于災難恢複；

4.2、主動模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master複制的兩台伺服器，既是master，又是另一台伺服器的slave。如圖：

主動的Master-Master複制有一些特殊的用處。例如，地理上分布的兩個部分都需要自己的可寫的資料副本。這種結構最大的問題就是更新沖突。假設一個表隻有一行(一列)的資料，其值為1，如果兩個伺服器分别同時執行如下語句：

在第一個伺服器上執行：

mysql> UPDATE tbl SET col=col + 1;

在第二個伺服器上執行：

mysql> UPDATE tbl SET col=col * 2;

那麼結果是多少呢？一台伺服器是4，另一個伺服器是3，但是，這并不會産生錯誤。

實際上，MySQL并不支援其它一些DBMS支援的多主伺服器複制(Multimaster Replication)，這是MySQL的複制功能很大的一個限制(多主伺服器的難點在于解決更新沖突)，但是，如果你實在有這種需求，你可以采用MySQL Cluster，以及将Cluster和Replication結合起來，可以建立強大的高性能的資料庫平台。但是，可以通過其它一些方式來模拟這種多主伺服器的複制。

4.3、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)

這是master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在于其中一個服務隻能進行隻讀操作。如圖：

4.4、帶從伺服器的Master-Master結構(Master-Master with Slaves)

這種結構的優點就是提供了備援。在地理上分布的複制結構，它不存在單一節點故障問題，而且還可以将讀密集型的請求放到slave上。

本文轉自小強測試幫 51CTO部落格，原文連結：http://blog.51cto.com/xqtesting/1658780，如需轉載請自行聯系原作者

mysql主從複制講解

繼續閱讀

Linxu常用指令技巧彙總

ERROR 1 (HY000): Can't create/write to file '/tmp/#sql_4188_1.MYI' (Errcode: 28)

艱難安裝LDAP,SSL認證

《Linux指令行與Shell腳本程式設計大全第2版.布盧姆》pdf

MySQL的4種隔離級别？出現問題

nginx location中斜線的位置的重要性

XX系統實施過程問題總結

無元件上傳圖檔到資料庫中，最完整解決方案

【MySQL資料庫】資料庫索引事務1.索引2.事務

neo4j之cypher使用文檔

NOSQL安全攻擊

mybatis_入門程式Mybatis入門

mysql使用source指令導入.sql檔案

登入plsql 報錯 the account is locked --使用者被鎖

sqlServer根據經緯查距離

SequoiaDB巨杉資料庫C++驅動概述