mysql （master/slave）複製原理及配置

時間 2019-11-26

標籤 mysql master slave 複製原理配置欄目 MySQL 简体版

原文原文鏈接

1 複製概述

Mysql內建的複製功能是構建大型，高性能應用程序的基礎。將Mysql的數據分佈到多個系統上去，這種分佈的機制，是經過將Mysql的某一臺主機的數據複製到其它主機（slaves）上，並從新執行一遍來實現的。複製過程當中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日誌文件，並維護文件的一個索引以跟蹤日誌循環。這些日誌能夠記錄發送到從服務器的更新。當一個從服務器鏈接主服務器時，它通知主服務器從服務器在日誌中讀取的最後一次成功更新的位置。從服務器接收從那時起發生的任何更新，而後封鎖並等待主服務器通知新的更新。java

請注意當你進行復制時，全部對複製中的表的更新必須在主服務器上進行。不然，你必需要當心，以免用戶對主服務器上的表進行的更新與對從服務器上的表所進行的更新之間的衝突。mysql

1.1 mysql支持的複製類型：

　　（１）：基於語句的複製：在主服務器上執行的SQL語句，在從服務器上執行一樣的語句。MySQL默認採用基於語句的複製，效率比較高。
一旦發現無法精確複製時，會自動選着基於行的複製。
　　（２）：基於行的複製：把改變的內容複製過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持
　　（３）：混合類型的複製: 默認採用基於語句的複製，一旦發現基於語句的沒法精確的複製時，就會採用基於行的複製。算法

1.2 . 複製解決的問題

         MySQL複製技術有如下一些特色：
         (1)   數據分佈 (Data distribution )
         (2)   負載平衡(load balancing)
         (3)   備份(Backups)
         (4)   高可用性和容錯行 High availability and failover sql

1.3 複製如何工做

總體上來講，複製有3個步驟： shell

       (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從線程）處理該過程的最後一步。SQL線程從中繼日誌讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌一般會位於OS的緩存中，因此中繼日誌的開銷很小。
        此外，在master中也有一個工做線程：和其它MySQL的鏈接同樣，slave在master中打開一個鏈接也會使得master開始一個線程。複製過程有一個很重要的限制——複製在slave上是串行化的，也就是說master上的並行更新操做不能在slave上並行操做。
服務器

2 .複製配置

有兩臺MySQL數據庫服務器Master和slave，Master爲主服務器，slave爲從服務器，初始狀態時，Master和slave中的數據信息相同，當Master 中的數據發生變化時，slave也跟着發生相應的變化，使得master和slave的數據信息同步，達到備份的目的。網絡

要點：
負責在主、從服務器傳輸各類修改動做的媒介是主服務器的二進制變動日誌，這個日誌記載着須要傳輸給從服務器的各類修改動做。所以，主服務器必須激活二進制日誌功能。從服務器必須具有足以讓它鏈接主服務器並請求主服務器把二進制變動日誌傳輸給它的權限。

環境：
Master和slave的MySQL數據庫版本同爲5.0.18
操做系統：unbuntu 11.10
IP地址：10.100.0.100
session

2.一、建立複製賬號

一、在Master的數據庫中創建一個備份賬戶：每一個slave使用標準的MySQL用戶名和密碼鏈接master。進行復制操做的用戶會授予REPLICATION SLAVE權限。用戶名的密碼都會存儲在文本文件master.info中

命令以下：
mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.*
TO backup@’10.100.0.200’
IDENTIFIED BY ‘1234’;

創建一個賬戶backup，而且只能容許從10.100.0.200這個地址上來登錄，密碼是1234。

(若是由於mysql版本新舊密碼算法不一樣，能夠設置：set password for 'backup'@'10.100.0.200'=old_password('1234')）

2.二、拷貝數據

（假如是你徹底新安裝mysql主從服務器，這個一步就不須要。由於新安裝的master和slave有相同的數據）

關停Master服務器，將Master中的數據拷貝到B服務器中，使得Master和slave中的數據同步，而且確保在所有設置操做結束前，禁止在Master和slave服務器中進行寫操做，使得兩數據庫中的數據必定要相同！

2.三、配置master

接下來對master進行配置，包括打開二進制日誌，指定惟一的servr ID。例如，在配置文件加入以下值：

server-id=1
log-bin=mysql-bin

server-id：爲主服務器A的ID值
log-bin：二進制變動日值

重啓master，運行SHOW MASTER STATUS，輸出以下：

2.四、配置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.五、啓動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的設置是否正確：

mysql> SHOW SLAVE STATUS\G

*************************** 1. row ***************************

Slave_IO_State:

Master_Host: server1

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 4

Relay_Log_File: mysql-relay-bin.000001

Relay_Log_Pos: 4

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: No

Slave_SQL_Running: No

...omitted...

Seconds_Behind_Master: NULL

Slave_IO_State, Slave_IO_Running, 和Slave_SQL_Running是No

代表slave尚未開始複製過程。日誌的位置爲4而不是0，這是由於0只是日誌文件的開始位置，並非日誌位置。實際上，MySQL知道的第一個事件的位置是4。

爲了開始複製，你能夠運行：

mysql> START SLAVE;

運行SHOW SLAVE STATUS查看輸出結果：

mysql> SHOW SLAVE STATUS\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: server1

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 164

Relay_Log_File: mysql-relay-bin.000001

Relay_Log_Pos: 164

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

...omitted...

Seconds_Behind_Master: 0

在這裏主要是看:
Slave_IO_Running=Yes
Slave_SQL_Running=Yes

slave的I/O和SQL線程都已經開始運行，並且Seconds_Behind_Master再也不是NULL。日誌的位置增長了，意味着一些事件被獲取並執行了。若是你在master上進行修改，你能夠在slave上看到各類日誌文件的位置的變化，一樣，你也能夠看到數據庫中數據的變化。

你可查看master和slave上線程的狀態。在master上，你能夠看到slave的I/O線程建立的鏈接：

在master上輸入show processlist\G;

mysql> show processlist \G

*************************** 1. row ***************************

Id: 1

User: root

Host: localhost:2096

db: test

Command: Query

Time: 0

State: NULL

Info: show processlist

*************************** 2. row ***************************

Id: 2

User: repl

Host: localhost:2144

db: NULL

Command: Binlog Dump

Time: 1838

State: Has sent all binlog to slave; waiting for binlog to be updated

Info: NULL

2 rows in set (0.00 sec)

行2爲處理slave的I/O線程的鏈接。

在slave服務器上運行該語句：

mysql> show processlist \G

*************************** 1. row ***************************

Id: 1

User: system user

Host:

db: NULL

Command: Connect

Time: 2291

State: Waiting for master to send event

Info: NULL

*************************** 2. row ***************************

Id: 2

User: system user

Host:

db: NULL

Command: Connect

Time: 1852

State: Has read all relay log; waiting for the slave I/O thread to update it

Info: NULL

*************************** 3. row ***************************

Id: 5

User: root

Host: localhost:2152

db: test

Command: Query

Time: 0

State: NULL

Info: show processlist

3 rows in set (0.00 sec)

行1爲I/O線程狀態，行2爲SQL線程狀態。

2.五、添加新slave服務器

假如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.一、基於語句的複製(Statement-Based Replication)

MySQL 5.0及以前的版本僅支持基於語句的複製（也叫作邏輯複製，logical replication），這在數據庫並不常見。master記錄下改變數據的查詢，而後，slave從中繼日誌中讀取事件，並執行它，這些SQL語句與 master執行的語句同樣。
這種方式的優勢就是實現簡單。此外，基於語句的複製的二進制日誌能夠很好的進行壓縮，並且日誌的數據量也較小，佔用帶寬少——例如，一個更新GB的數據的查詢僅須要幾十個字節的二進制日誌。而mysqlbinlog對於基於語句的日誌處理十分方便。

可是，基於語句的複製並非像它看起來那麼簡單，由於一些查詢語句依賴於master的特定條件，例如，master與slave可能有不一樣的時間。所以，MySQL的二進制日誌的格式不只僅是查詢語句，還包括一些元數據信息，例如，當前的時間戳。即便如此，仍是有一些語句，好比，CURRENT USER函數，不能正確的進行復制。此外，存儲過程和觸發器也是一個問題。
另一個問題就是基於語句的複製必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。並非全部的存儲引擎都支持基於語句的複製。

3.二、基於記錄的複製(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.三、複製相關的文件

除了二進制日誌和中繼日誌文件外，還有其它一些與複製相關的文件。以下：

(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文件，內容以下(個人機器上)：

.\mysql-02-relay-bin.000019

254

mysql-01-bin.000010

286

52813

(4)relay-log.info

包含slave中當前二進制日誌和中繼日誌的信息。

3.四、發送複製事件到其它slave

當設置log_slave_updates時，你可讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行本身的二進制日誌(binary log)，而後，它的slave能夠獲取這些事件並執行它。以下：

3.五、複製過濾(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.一、單一master和多slave

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

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

4.二、主動模式的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結合起來，能夠創建強大的高性能的數據庫平臺。可是，能夠經過其它一些方式來模擬這種多主服務器的複製。