mysql 主從複製 雙主從複製原理 防止主鍵重複問題(必看)

雙機熱備的概念簡單說一下，就是要保持兩個數據庫的狀態自動同步。對任何一個數據庫的操做都自動應用到另一個數據庫，始終保持兩個數據庫數據一致。 這樣作的好處多。 1. 能夠作災備，其中一個壞了能夠切換到另外一個。 2. 能夠作負載均衡，能夠將請求分攤到其中任何一臺上，提升網站吞吐量。  對於異地熱備，尤爲適合災備。廢話很少說了。咱們直接進入主題。 咱們會主要介紹兩部份內容：

一， mysql 備份工做原理

二， 備份實戰

 

咱們開始。

我使用的是mysql 5.5.34，

 

 

一， mysql 備份工做原理

簡單的說就是把 一個服務器上執行過的sql語句在別的服務器上也重複執行一遍， 這樣只要兩個數據庫的初態是同樣的，那麼它們就能一直同步。

 

固然這種複製和重複都是mysql自動實現的，咱們只須要配置便可。

 

咱們進一步詳細介紹原理的細節， 這有一張圖：

上圖中有兩個服務器， 演示了從一個主服務器（master） 把數據同步到從服務器（slave）的過程。

這是一個主-從複製的例子。 主-主互相複製只是把上面的例子反過來再作一遍。 因此咱們以這個例子介紹原理。

 

對於一個mysql服務器， 通常有兩個線程來負責複製和被複制。當開啓複製以後。

 

1. 做爲主服務器Master，  會把本身的每一次改動都記錄到 二進制日誌 Binarylog 中。 （從服務器會負責來讀取這個log， 而後在本身那裏再執行一遍。）

 

2. 做爲從服務器Slave， 會用master上的帳號登錄到 master上， 讀取master的Binarylog,  寫入到本身的中繼日誌 Relaylog， 而後本身的sql線程會負責讀取這個中繼日誌，並執行一遍。  到這裏主服務器上的更改就同步到從服務器上了。

 

在mysql上能夠查看當前服務器的主，從狀態。 其實就是當前服務器的 Binary（做爲主服務器角色）狀態和位置。 以及其RelayLog（做爲從服務器）的複製進度。

 

例如咱們在主服務器上查看主狀態：

 

mysql> show master status\G
*************************** 1. row ***************************
            File: mysql-bin.000014
        Position: 107
    Binlog_Do_DB: 
Binlog_Ignore_DB: mysql,information_schema,performance_schema,amh
1 row in set (0.00 sec)

稍微解釋一下這幾行的意思：

1. 第一行代表 當前正在記錄的 binarylog文件名是： mysql-bin.000014.

咱們能夠在mysql數據目錄下，找到這個文件：

 

2.  第二行， 107. 表示當前的文件偏移量， 就是寫入在mysql-bin.000014 文件的記錄位置。

這兩點就構成了 主服務器的狀態。  配置從服務器的時候，須要用到這兩個值。 告訴從服務器從哪讀取主服務器的數據。 （從服務器會登陸以後，找到這個日誌文件，並從這個偏移量以後開始複製。）

 

3. 第三行，和第四行，表示須要記錄的數據庫和須要忽略的數據庫。 只有須要記錄的數據庫，其變化纔會被寫入到mysql-bin.000014日誌文件中。  後面會再次介紹這兩個參數。

 

咱們還能夠在從服務器上，查看從服務器的複製狀態。

 

   1:  mysql> show slave status\G

   2:  *************************** 1. row ***************************

   3:                 Slave_IO_State: Waiting for master to send event

   4:                    Master_Host: 198.**.***.***

   5:                    Master_User: r*******

   6:                    Master_Port: 3306

   7:                  Connect_Retry: 60

   8:                Master_Log_File: mysql-bin.000014

   9:            Read_Master_Log_Pos: 107

  10:                 Relay_Log_File: mysqld-relay-bin.000013

  11:                  Relay_Log_Pos: 253

  12:          Relay_Master_Log_File: mysql-bin.000014

  13:               Slave_IO_Running: Yes

  14:              Slave_SQL_Running: Yes

  15:                Replicate_Do_DB: 

  16:            Replicate_Ignore_DB: mysql,information_schema,amh,performance_schema

  17:             Replicate_Do_Table: 

  18:         Replicate_Ignore_Table: 

  19:        Replicate_Wild_Do_Table: 

  20:    Replicate_Wild_Ignore_Table: 

  21:                     Last_Errno: 0

  22:                     Last_Error: 

  23:                   Skip_Counter: 0

  24:            Exec_Master_Log_Pos: 107

  25:                Relay_Log_Space: 556

  26:                Until_Condition: None

  27:                 Until_Log_File: 

  28:                  Until_Log_Pos: 0

  29:             Master_SSL_Allowed: No

 

咱們仍是來重點解釋途中的紅圈的部分：

1.  Master_host 指的是 主服務器的地址。 

2. Master_user 指的是主服務器上用來複制的用戶。  從服務器會用此帳號來登陸主服務。進行復制。

3. Master_log_file 就是前面提到的， 主服務器上的日誌文件名.

4. Read_Master_log_pos 就是前面提到的主服務器的日誌記錄位置， 從服務器根據這兩個條件來選擇複製的文件和位置。

5. Slave_IO_Running:  指的就是從服務器上負責讀取主服務器的線程工做狀態。 從服務器用這個專門的線程連接到主服務器上，並把日誌拷貝回來。

6. Slave_SQL_Running: 指的就是專門執行sql的線程。 它負責把複製回來的Relaylog執行到本身的數據庫中。 這兩個參數必須都爲Yes 才代表複製在正常工做。

 

其餘的參數以後再介紹。

 

 

二， mysql 雙機熱備實戰

瞭解了上面的原理以後， 咱們來實戰。 這裏有兩個重點， 要想同步數據庫狀態， 須要相同的初態，而後配置同步纔有意義。 固然你能夠不要初態，這是你的自由。 咱們這裏從頭開始配置一遍。

 

 

咱們先以A服務器爲起點，  配置它的數據庫同步到B。  這就是主-從複製了。 以後再反過來作一次，就能夠互相備份了。

 

1， 第一步，

在A上面建立專門用於備份的 用戶：

 

grant replication slave on *.* to 'repl_user'@'192.***.***.***' identified by 'hj34$%&mnkb';

 

上面把ip地址換成B機器的ip地址。 只容許B登陸。安全。

用戶名爲： repl_user

密碼爲： hj34$********nkb

這個等會在B上面要用。

 

2. 開啓主服務器的 binarylog。

不少服務器是默認開啓的，咱們這裏檢查一下：

打開 /etc/my.cnf

 

 

我來解釋一下紅框中的配置：

前面三行， 你可能已經有了。

binlog-do-db 用來表示，只把哪些數據庫的改動記錄到binary日誌中。 能夠寫上關注hello數據庫。 可是我把它註釋掉了。 只是展現一下。 能夠寫多行，表示關注多個數據庫。

binlog-ignore-db 表示，須要忽略哪些數據庫。我這裏忽略了其餘的4個數據庫。

 

後面兩個用於在 雙主（多主循環）互相備份。 由於每臺數據庫服務器均可能在同一個表中插入數據，若是表有一個自動增加的主鍵，那麼就會在多服務器上出現主鍵衝突。  解決這個問題的辦法就是讓每一個數據庫的自增主鍵不連續。  上圖說是， 我假設須要未來可能須要10臺服務器作備份， 因此auto-increment-increment 設爲10.   而 auto-increment-offset=1 表示這臺服務器的序號。 從1開始， 不超過auto-increment-increment。

這樣作以後， 我在這臺服務器上插入的第一個id就是 1， 第二行的id就是 11了， 而不是2.

（同理，在第二臺服務器上插入的第一個id就是2， 第二行就是12， 這個後面再介紹） 這樣就不會出現主鍵衝突了。 後面咱們會演示這個id的效果。

 

3.  獲取主服務器狀態， 和同步初態。

假設我如今有這些數據庫在A上面。

若是你是全新安裝的， 那麼不須要同步初態，直接跳過這一步，到後面直接查看主服務器狀態。

這裏咱們假設有一個 hello 數據庫做爲初態。

 

 

先鎖定 hello數據庫：

FLUSH TABLES WITH READ LOCK;

 

 

而後導出數據：

我這裏只須要導出hello數據庫， 若是你有多個數據庫做爲初態的話， 須要導出全部這些數據庫：

 

 

而後查看A服務器的binary日誌位置：

記住這個文件名和 位置， 等會在從服務器上會用到。

 

 

主服務器已經作完了， 能夠解除鎖定了：

 

 

 

4.  設置從服務器 B 須要複製的數據庫

打開從服務器 B 的 /etc/my.cnf 文件：

 

 

 

解釋一下上面的內容。

server-id 必須保證每一個服務器不同。 這可能和循環同步有關。 防止進入死循環。

replicate-do-db 能夠指定須要複製的數據庫， 我這裏注掉了。 演示一下。

replicate-ignore-db 複製時須要排除的數據庫， 我使用了，這個。 除開系統的幾個數據庫以外，全部的數據庫都複製。

relay_log 中繼日誌的名字。 前面說到了， 複製線程須要先把遠程的變化拷貝到這個中繼日誌中， 在執行。

log-slave-updates 意思是，中繼日誌執行以後，這些變化是否須要計入本身的binarylog。 當你的B服務器須要做爲另一個服務器的主服務器的時候須要打開。  就是雙主互相備份，或者多主循環備份。 咱們這裏須要， 因此打開。

 

保存， 重啓mysql。

 

 

5. 導入初態， 開始同步。

把剛纔從A服務器上導出的 hello.sql 導入到 B的hello數據庫中， 若是B如今沒有hello數據庫，請先建立一個， 而後再導入：

建立數據庫：

mysql> create database hello default charset utf8;

把hello.sql 上傳到B上， 而後導入：

 

若是你剛纔導出了多個數據庫， 須要把他們都一一上傳導入。

 

開啓同步, 在B服務器上執行：

 CHANGE MASTER TO 
       MASTER_HOST='192.***.***.***', 
       MASTER_USER='repl_user', 
       MASTER_PASSWORD='hj3****', 
       MASTER_LOG_FILE='mysql-bin.000004', 
       MASTER_LOG_POS=7145;

 

上面幾個參數我就不解釋了。 前面說過了。

 

重啓mysql，  而後查看slave線程開啓了沒：

 

 

注意圖中的紅框， 兩個都是Yes， 說明開啓成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

若是其中一個是No， 那就說明不成功。須要查看mysql的錯誤日誌。 我在第一次作的時候就遇到這個問題。有時候密碼填錯了， 有時候防火牆的3306沒有打開。ip地址不對，等等。 都會致使失敗。

 

咱們看錯誤日誌: mysql的錯誤日誌通常在：

 

文件名應該是你的機器名， 我這裏叫作host1.err 你換成你本身的。

 

到這裏主-從複製已經打開了。 咱們先來實驗一下。

咱們在A的數據庫裏面去 添加數據：

 

我在A的 hello數據庫的test表中 連續插入了3條數據，  注意看他們的自增加id， 分別是1,11,21.  知道這是爲何嗎。 前面已經說過了，不懂再回去看。

 

咱們去看一下B數據庫有沒有這三條數據：

 

打開B的數據庫：

發現已經在這了。 這裏效果不直觀。

 

此時不要在B中修改數據。 咱們接着配置從B到A的複製。  若是你只須要主從複製的話， 到這裏就結束了。後面能夠不看了。 全部A中的修改都能自動同步到B， 可是對B的修改卻不能同步到A。 由於是單向的。 若是須要雙向同步的話，須要再作一次從B到A的複製。

 

基本跟上面同樣：咱們簡單一點介紹：

 

1. 在B中建立用戶；

 

2. 打開 /etc/my.cnf ， 開啓B的binarylog：

注意紅框中所新添加的部分。

 

3. 咱們不須要導出B的初態了，由於它剛剛纔從A導過來。  直接記住它的master日誌狀態：

 

記住這兩個數值，等會在A上面要用。

B服務器就設置完了。

 

4. 登陸到A 服務器。 開啓中繼：

 

注意框中心添加的部分， 不解釋了。

 

5. 啓動同步：

上面的ip地址是B的ip地址， 由於A把B當作master了。 不解釋了。

 

而後重啓mysql服務。

而後查看，slave狀態是否正常：

 

圖中出現了兩個No。

Slave_IO_Running: No

Slave_SQL_Running: No

說明slave沒有成功， 即，從B到A的同步沒有成功。 咱們去查看mysql錯誤日誌，前面說過位置：

 

 

找到  機器名.err 文件，打開看看：

 

看圖中的error信息。  說找不到中繼日誌文件。

這是由於咱們在配置A的中繼文件時改了中繼文件名，可是mysql沒有同步。解決辦法很簡單。

 

 

先停掉mysql服務。  找到這三個文件，把他們刪掉。 必定要先停掉mysql服務。否則仍是不成功。你須要重啓一下機器了。 或者手動kill mysqld。

好了， 啓動mysql以後。 咱們在來檢查一下slave狀態：

 

 

注意圖中兩個大大的Yes。

 

 

 

 

1 複製概述

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

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

1.1 mysql支持的複製類型：

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

 1.2 . 複製解決的問題

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

  1.3 複製如何工做 

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

       (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

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 0 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進行通訊。

在實際應用場景中，MySQL複製90%以上都是一個Master複製到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。由於只要Master和Slave的壓力不是太大（尤爲是Slave端壓力）的話，異步複製的延時通常都不多不多。尤爲是自從Slave端的複製方式改爲兩個線程處理以後，更是減少了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別Critical的應用，只須要經過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多臺Slave的機器上面，便可經過分散單臺數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力仍是要比寫壓力大不少。這在很大程度上解決了目前不少中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用相似方案解決數據庫瓶頸。

以下：

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

 

你們應該都比較清楚，從一個Master節點能夠複製出多個Slave節點，可能有人會想，那一個Slave節點是否能夠從多個Master節點上面進行復制呢？至少在目前來看，MySQL是作不到的，之後是否會支持就不清楚了。

MySQL不支持一個Slave節點從多個Master節點來進行復制的架構，主要是爲了不衝突的問題，防止多個數據源之間的數據出現衝突，而形成最後數據的不一致性。不過據說已經有人開發了相關的patch，讓MySQL支持一個Slave節點從多個Master結點做爲數據源來進行復制，這也正是MySQL開源的性質所帶來的好處。

 

 

4.二、主動模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master複製的兩臺服務器，既是master，又是另外一臺服務器的slave。這樣，任何一方所作的變動，都會經過複製應用到另一方的數據庫中。

可能有些讀者朋友會有一個擔憂，這樣搭建複製環境以後，難道不會形成兩臺MySQL之間的循環複製麼？實際上MySQL本身早就想到了這一點，因此在MySQL的BinaryLog中記錄了當前MySQL的server-id，並且這個參數也是咱們搭建MySQLReplication的時候必須明確指定，並且Master和Slave的server-id參數值比須要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值以後，MySQL就很容易判斷某個變動是從哪個MySQLServer最初產生的，因此就很容易避免出現循環複製的狀況。並且，若是咱們不打開記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄複製過程當中的變動到BinaryLog中，就更不用擔憂可能會出現循環複製的情形了。

 

如圖：

 

主動的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.三、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)

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

 

 

4.4 級聯複製架構 Master –Slaves - Slaves

在有些應用場景中，可能讀寫壓力差異比較大，讀壓力特別的大，一個Master可能須要上10臺甚至更多的Slave纔可以支撐注讀的壓力。這時候，Master就會比較吃力了，由於僅僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點的時候，Master端由於複製就會消耗較多的資源，很容易形成複製的延時。

遇到這種狀況如何解決呢？這時候咱們就能夠利用MySQL能夠在Slave端記錄複製所產生變動的BinaryLog信息的功能，也就是打開—log-slave-update選項。而後，經過二級（或者是更多級別）複製來減小Master端由於複製所帶來的壓力。也就是說，咱們首先經過少數幾臺MySQL從Master來進行復制，這幾臺機器咱們姑且稱之爲第一級Slave集羣，而後其餘的Slave再從第一級Slave集羣來進行復制。從第一級Slave進行復制的Slave，我稱之爲第二級Slave集羣。若是有須要，咱們能夠繼續往下增長更多層次的複製。這樣，咱們很容易就控制了每一臺MySQL上面所附屬Slave的數量。這種架構我稱之爲Master-Slaves-Slaves架構

這種多層級聯複製的架構，很容易就解決了Master端由於附屬Slave太多而成爲瓶頸的風險。下圖展現了多層級聯複製的Replication架構。

固然，若是條件容許，我更傾向於建議你們經過拆分紅多個Replication集羣來解決

上述瓶頸問題。畢竟Slave並無減小寫的量，全部Slave實際上仍然仍是應用了全部的數據變動操做，沒有減小任何寫IO。相反，Slave越多，整個集羣的寫IO總量也就會越多，咱們沒有很是明顯的感受，僅僅只是由於分散到了多臺機器上面，因此不是很容易表現出來。

此外，增長複製的級聯層次，同一個變動傳到最底層的Slave所須要通過的MySQL也會更多，一樣可能形成延時較長的風險。

而若是咱們經過分拆集羣的方式來解決的話，可能就會要好不少了，固然，分拆集羣也須要更復雜的技術和更復雜的應用系統架構。

 4.五、帶從服務器的Master-Master結構(Master-Master with Slaves)

這種結構的優勢就是提供了冗餘。在地理上分佈的複製結構，它不存在單一節點故障問題，並且還能夠將讀密集型的請求放到slave上。

 

 

級聯複製在必定程度上面確實解決了Master由於所附屬的Slave過多而成爲瓶頸的問題，可是他並不能解決人工維護和出現異常須要切換後可能存在從新搭建Replication的問題。這樣就很天然的引伸出了DualMaster與級聯複製結合的Replication架構，我稱之爲Master-Master-Slaves架構

和Master-Slaves-Slaves架構相比，區別僅僅只是將第一級Slave集羣換成了一臺單獨的Master，做爲備用Master，而後再從這個備用的Master進行復制到一個Slave集羣。

這種DualMaster與級聯複製結合的架構，最大的好處就是既能夠避免主Master的寫入操做不會受到Slave集羣的複製所帶來的影響，同時主Master須要切換的時候也基本上不會出現重搭Replication的狀況。可是，這個架構也有一個弊端，那就是備用的Master有可能成爲瓶頸，由於若是後面的Slave集羣比較大的話，備用Master可能會由於過多的SlaveIO線程請求而成爲瓶頸。固然，該備用Master不提供任何的讀服務的時候，瓶頸出現的可能性並非特別高，若是出現瓶頸，也能夠在備用Master後面再次進行級聯複製，架設多層Slave集羣。固然，級聯複製的級別越多，Slave集羣可能出現的數據延時也會更爲明顯，因此考慮使用多層級聯複製以前，也須要評估數據延時對應用系統的影響。

當一我的找不到出路的時候，最好的辦法就是將當前能作好的事情作到極致，作到無人能及