MySQL 5.5 手冊17.1.1：如何設置複製（Replication）

注意：

1. 本文的原文是MySQL 5.5官方手冊中的17.1.1 http://dev.mysql.com/doc/refman/5.5/en/replication-howto.html。

2. 本文的超鏈接全部來自於原文，超鏈接對應的文章沒有進行翻譯，但是如果超鏈接如果在17.1.1.1-17.1.1.10之中，那全都翻譯了，繼續閱讀本文即可。

目錄：

17.1.1.1 Setting the Replication Master Configuration

17.1.1.2 Setting the Replication Slave Configuration

17.1.1.3 Creating a User for Replication

17.1.1.4 Obtaining the Replication Master Binary Log Coordinates

17.1.1.5 Creating a Data Snapshot Using mysqldump

17.1.1.6 Creating a Data Snapshot Using Raw Data Files

17.1.1.7 Setting Up Replication with New Master and Slaves

17.1.1.8 Setting Up Replication with Existing Data

17.1.1.9 Introducing Additional Slaves to an Existing Replication Environment

17.1.1.10 Setting the Master Configuration on the Slave

這一節描述瞭如何完整地配置MySQL的Replication。設置複製的方法很多，具體用哪種方法取決於你如何配置，以及你的主庫中是否有數據。

不管什麼方法，以下這些配置是通用的，都要完成。

• 主庫必須要開啓二進制日誌，並賦予一個唯一的服務器ID。配置好後可能需要重啓MySQL。細節可查看Section 17.1.1.1, “Setting the Replication Master Configuration”.
• 要給所有的從庫都賦予一個唯一（主、從庫的ID全都不能相同）的服務器ID。配置好後可能需要重啓MySQL。細節可查看Section 17.1.1.2, “Setting the Replication Slave Configuration”.
• 最好在主庫上爲從庫創建一個複製專用的數據庫賬戶。這一步是可選的。細節可查看Section 17.1.1.3, “Creating a User for Replication”.
  
• 在創建數據快照（data snapshot）或啓動複製線程（replication process）之前，必須要先記錄下主庫的二進制日誌座標。配置從庫的時候，這個值可以讓從庫知道從主庫二進制日誌的什麼地方開始執行事件。細節可查看Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”.
• 如果主庫中已經有數據，並且一併同步到從庫中，這是需要創建一個數據快照（data snapshot）。可以使用mysqldump創建快照（參見Section 17.1.1.5, “Creating a Data Snapshot Using mysqldump”）或直接拷貝數據文件（參見Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”）。
• 最後需要配置從庫如何連接到主庫，包括主機名、登錄認證信息、二進制日誌文件名和二進制日誌座標。細節可查看Section 17.1.1.10, “Setting the Master Configuration on the Slave”.

如果你配置好了以上的基本內容，就可以進行繼續的配置，以下是一些可選的步驟：

• 如果你的主庫是空的，且有一個或多個從庫，你只需要進行以下配置：Section 17.1.1.7, “Setting Up Replication with New Master and Slaves”.
• 如果主庫已經有數據但以前從未開啓過二進制日誌，但還需要將這些數據複製到從庫，可以參考這裏：Section 17.1.1.8, “Setting Up Replication with Existing Data”.注意：此種方法需要關閉主庫一段時間。
• 如果需要將一個從庫加入到已有的複製環境中，可以這樣配置且不影響主庫工作：Section 17.1.1.9, “Introducing Additional Slaves to an Existing Replication Environment”.

如果你打算管理MySQL複製服務器，我們建議你閱讀整章，以及Section 13.4.1, “SQL Statements for Controlling Master Servers”和Section 13.4.2, “SQL Statements for Controlling Slave Servers”提到的內容。你還應該熟悉一些和複製有關的啓動參數：Section 17.1.3, “Replication and Binary Logging Options and Variables”.

注意：
配置時的有些步驟需要超級用戶SUPER的權限。如果沒有這個權限，可能會導致配置失敗。

17.1.1.1 配置主庫（Setting the Replication Master Configuration）

主庫必須要開啓二進制日誌，並賦予一個唯一的server ID。完成這一步最後或許需要重啓MySQL。

必須要開啓二進制日誌的原因是：二進制日誌是主、從庫之間傳遞數據的根本。如果沒有二進制日誌，複製就不可能進行。

複製組（replication group）中的每一個server都必須要有一個唯一的server ID。這個ID用來區分複製組中不同server的身份，server ID的取值範圍是1~2^32-1中間的任意整數（注意，在MySQL 5.6以後，用server_uuid取代了server_id，且是自動生成，無需手動配置——譯者注）。怎麼配置這些值完全取決於你自己。要配置二進制日誌和serverid選項，需要關閉MySQL，然後編輯my.cnf或my.ini。下面的這兩個參數都在[mysqld]節點下。如果這兩個參數被註釋掉了，那麼請取消註釋並按照你的需要配置相應的參數。例如，要規定二進制文件的前綴是"mysql-bin"，且server id爲1，應該這麼配置：

[mysqld]
log-bin=mysql-bin
server-id=1

修改參數後，重啓MySQL。

注意一：
如果刪除server-id或配置爲0，那麼主庫將會拒絕任何從庫的連接。

注意二：
爲了保證InnoDB事務一致性的質量，建議把my.cnf中的innodb_flush_log_at_trx_commit和sync_binlog都配置爲1。

注意三：
確保主庫上的skip-networking參數沒有被禁用。如果這個參數被禁用，主、從庫之間將無法通信，導致複製失敗。

17.1.1.2 配置從庫（Setting the Replication Slave Configuration）

從庫必須要有一個唯一的server ID。完成這一步最後或許需要重啓MySQL。

如果從庫沒有server id，或者和主庫的id衝突，需要關閉MySQL並重選一個id，例如：

[mysqld]
server-id=2

修改參數後重啓MySQL。

如果要配置多個從庫，則每個都要有一個唯一的server-id。且互不相同。可以把server-id類比爲IP：ID就是複製組中的唯一標識碼。

注意：
如果刪除了server-id或配置爲0，該從庫將會拒絕連接任何主庫。

從庫可以不用開啓二進制日誌。不過，如果啓用了從庫的二進制日誌，可以用來進行數據備份或崩潰後的恢復，統一可以創建更復雜的複製拓撲，如改從庫是其他從庫的主庫。

17.1.1.3 創建複製專用賬戶（Creating a User for Replication）

從庫連到主庫必須要有MySQL的用戶名和密碼，因此主庫上需要有一個賬戶用來進行復制。任何有REPLICATION SLAVE權限的賬戶都可以。每個從庫可以有自己的用戶名，也可以所有從庫共用同一個用戶名。

複製並不需要一個單獨的用戶名，但是用於複製的用戶名和密碼都會被以明文的方式存儲在master.info中（可參見Section 17.2.2.2, “Slave Status Logs”）。因此最好爲複製創建一個獨立的用戶名，並且僅賦予最小權限（即REPLICATION SLAVE）。

用CREATE USER可以創建新用戶，之後用GRANT賦權。如果這個用戶名只用來複制，那麼REPLICATION SLAVE權限就足夠了。例如：創建一個名爲repl，密碼是slavepass，可以在mydomain.com域下使用的用戶語句如下：

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

關於用戶賬戶的更多細節，請參見Section 13.7.1, “Account Management Statements”。

17.1.1.4 獲得主庫的二進制日誌座標（Obtaining the Replication Master Binary Log Coordinates）

在從庫上配置複製時，需要配置主庫的二進制日誌座標。這個值可以保證從庫從二進制日誌的正確位置讀取信息。

如果主庫上有一些數據是在複製以前產生的，而且也需要同步到從庫，需要先停止主庫上的相關操作（stop processing statements on the master），獲取二進制日誌座標，轉存數據（dump its data）。如果沒有停止運行部分，將會導致最終從庫數據的不正確。

以下步驟可以獲得主庫的二進制日誌座標：

1. 用命令行客戶端連接到主庫上，並使用FLUSH TABLES WITH READ LOCK情況所有表和塊，鎖定所有表

          mysql> FLUSH TABLES WITH READ LOCK;

           值得注意的是InnoDB表中，FLUSH TABLES WITH READ LOCK還會鎖定COMMIT操作

警告
保證你執行FLUSH TABLES的客戶端一直處於激活狀態，這樣讀鎖才能一直起作用。如果你退出了客戶端，那麼鎖就被釋放了。

        2. 在另外一個連接到主庫的會話中，用SHO MASTER STATUS查看二進制日誌的名稱和位置：

mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73       | test         | manual,mysql     |
+------------------+----------+--------------+------------------+

File列顯示了日誌文件的文件名，Position則記錄了日誌中的位置。在這個例子中，二進制文件名爲mysql-bin.000003，位置是73。記錄下這些值，在一會配置從庫時會用到。這些值表示從庫讀取日誌時的起點。

如果主庫在開啓二進制日誌前就運行了，SHOW MASTER STATUS或mysqldump --master-data將會返回空值。這種情況下，一會填寫日誌文件名和位置的時候，請使用空字符串（‘’）和4。

現在已經獲得了二進制日誌座標。

如果在複製開始前，就有數據，且需要同步到從庫，保持讀鎖，並參見Section 17.1.1.5, “Creating a Data Snapshot Using mysqldump”或Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”。這麼做是爲了防止任何進一步的改變，以保證從庫和主庫同步。

如果主庫什麼都沒有，那麼可以退出最早的會話釋放讀鎖。

17.1.1.5 使用mysqldump創建數據快照（Creating a Data Snapshot Using mysqldump）

爲主庫的已有數據創建快照的方法之一是使用mysqldump。一旦dump結束，可以在從庫複製前導入這些數據。

下面的例子演示了將所有的數據庫dump到一個叫dbdump.db的文件中，其中的--master-date參數會自動添加CHANGE MASTER TO信息。

shell> mysqldump --all-databases --master-data > dbdump.db

如果不使用--master-data，則需要在一個獨立的會話（sessing）中手動的使用FLUSH TABLES WITH READ LOCK鎖定所有的表再運行mysqldump，然後退出或在另外一個會話中使用UNLOCK TABLES解鎖。同時需要使用SHOW MASTER STATUS，以獲取從庫CHANGE MASTER TO的必要參數值。

如果dump不是包含所有的數據庫，那麼複製的時候也要注意，不要包含所有的庫。

導入數據既可以將dump文件拷到從庫，也可以從主庫遠程連接到從庫。

17.1.1.6 使用原始數據文件創建數據快照（Creating a Data Snapshot Using Raw Data Files）

如果你的數據庫很大，直接拷貝原始數據文件將會比mysqldump高效得多。這種方法可以越過索引對INSERT造成的限制（This technique skips the overhead of updating indexes as theINSERT statements are replayed.）

爲了能讓存儲引擎中的表使用這種方法與複雜的緩存和日誌算法一起形成一個完美的“時間點”，還需要一些額外的步驟：即使設定了全局讀鎖，也可能在拷貝的時候遺漏緩存數據和日誌更新。存儲引擎如何響應這些，取決於它防崩潰的水平。

這種方法不太適合以下幾種情況：主庫和從庫的ft_stopword_file、ft_min_word_len和ft_max_word_len參數不同，或者拷貝的表中有全文索引。

如果表的引擎是InnoDB，那麼可以考慮使用MySQL商業版中的mysqlbackup創建快照。詳情可見Section 25.2, “MySQL Enterprise Backup，

另外，可以使用冷備份方法獲得InnoDB表相關的二進制快照：在MySQL慢關閉以後，拷貝所有的數據文件。

爲MyISAM表創建一個原始數據快照的方法很多，可以使用標準的複製工具如cp或copy，遠程複製工具如scp或rsync，壓縮工具如zip或tar，或文件系統快照工具如dump。如果只備份一部分庫，則只備份與這些表相關的文件即可（InnoDB的所有數據都存儲在系統表空間文件中，除非你開啓了innodb_file_per_table選項）。

備份的時候要記得排除以下文件：

• mysql系統庫
• master.info文件
• 主庫的二進制文件
• 所有的relay log文件

爲了獲得最準確的原始數據快照，需要關閉主庫，之後按照以下描述操作：

1. 取得讀鎖並獲得主庫的狀態，可參見Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”

2. 在一個獨立的會話關閉主庫

shell> mysqladmin shutdown

3. 拷貝MySQL的數據文件。可以照後面的語句做，但你只需要執行其中一條語句即可

shell> tar cf /tmp/db.tar ./data
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata

4. 重啓主庫。

如果沒有使用InnoDB表，則獲取快照時可以不用關閉服務器，按照以下步驟操作即可：

1. 取得讀鎖並獲得主庫的狀態，可參見Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”

2. 拷貝MySQL的數據文件。可以照後面的語句做，但你只需要執行其中一條語句即可

shell> tar cf /tmp/db.tar ./data
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata

3. 解鎖主庫。

mysql> UNLOCK TABLES;

最後，將備份好的數據文件拷貝到從庫。

17.1.1.7 用新主庫和從庫搭建複製環境（Setting Up Replication with New Master and Slaves）

搭建複製環境最簡單直接的方法就是使用新的主庫和從庫。

這個方法還可以用於向複製環境中導入其他服務器的數據。只需要將數據導入到主庫中，就會被自動同步到所有的從庫。

具體步驟如下（假設主庫、從庫全部處於關閉狀態）：

1.  修改主庫配置文件。參見：Section 17.1.1.1, “Setting the Replication Master Configuration”。

2.  啓動主庫。

3.  配置複製用賬戶。參見：Section 17.1.1.3, “Creating a User for Replication”。

4.  獲得主庫的狀態信息。參見：Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”。

5.  主庫釋放讀鎖

mysql> UNLOCK TABLES;

6.  修改從庫配置文件。參見：Section 17.1.1.2, “Setting the Replication Slave Configuration”。

7.  啓動從庫。

8.  執行CHANGE MASTER TO語句爲從庫配置必要的主庫信息。參見Section 17.1.1.10, “Setting the Master Configuration on the Slave”。

在所有的從庫上重複6-8步。

由於主庫是空的，所以不用導入任何信息。

向主庫導入數據的步驟如下：

shell> mysql -h master < fulldb.dump

17.1.1.8  如何配置主庫非空的複製環境（Setting Up Replication with Existing Data）

當主庫中有數據時，就需要選擇最好的方法，使數據能夠完整的全部同步到從庫。

最基本的操作方法如下：

1.  配置複製用賬戶。參見：Section 17.1.1.3, “Creating a User for Replication”。

2.  如果沒有配置server-id或沒有打開二進制日誌，那麼停止服務器，並配置他們。參見：Section 17.1.1.1, “Setting the Replication Master Configuration”。如果服務器沒有啓動，這時應該趁機創建一個快照，並獲得服務器的主庫狀態（參見Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”），更新配置文件。如何使用原始文件創建快照可以參見：Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”。

3.  如果主庫已經配置好了，就應該先獲得主庫的狀態（參見Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”），然後使用mysqldump獲得快照（參見Section 17.1.1.5, “Creating a Data Snapshot Using mysqldump”）或使用原始文件創建快照可以參見：Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”。

4.  修改從庫配置文件。參見：Section 17.1.1.2, “Setting the Replication Slave Configuration”。

5.  接下來選用哪種方法，取決於你使用那種方式創建快照。如果使用mysqldump：

     a.  啓動從庫，使用--skip-slave-start選項確保複製沒有同時啓動

     b.  導入dump文件

      shell> mysql < fulldb.dump

     如果使用原始文件的方式：

     a.  在從庫的數據目錄解壓備份文件，如：

      shell> tar xvf dbdump.tar

           請確保當前的系統賬戶有足夠的權限，可以對相應的文件或文件夾進行修改

      b.  啓動從機，使用--ship-slave-start以確保複製沒有同時啓動。

6.  使用CHANGE MASTER TO配置從庫的二進制日誌座標。參見：Section 17.1.1.10, “Setting the Master Configuration on the Slave”。

7.  啓動從庫線程：

mysql> START SLAVE;

完成以上步驟後，從庫就可以連接到主庫同步了。

如果沒有設置主庫的server-id，從庫將找不到主庫。如果從庫沒有配置server-id，將會在從庫的日誌中看到如下信息：

Warning: You should set server-id to a non-0 value if master_host
is set; we will force server id to 2, but this MySQL server will
not act as a slave.

如果還有其他原因導致複製失敗，也可以在從庫的錯誤日誌中查找原因。

如果從庫開始複製操作，則可以在數據目錄看到一個名爲master.info和relay-log.info的文件。從庫用這兩個文件記錄主庫日誌它已經處理了多少。除非你真的知道刪除或修改這兩個文件帶來的影響，否則絕對不要這麼幹。如果發生這種情況，推薦使用CHANGE MASTER TO語句，讓從庫自動更新狀態文件。

注意：
master.info會覆寫一些啓動參數以及my.cnf的配置，詳情請參見Section 17.1.3, “Replication and Binary Logging Options and Variables”。

多個從庫可以共用同一個主庫快照。給從庫配置相同的座標即可。

17.1.1.9  爲已有複製環境增加新的從庫（Introducing Additional Slaves to an Existing Replication Environment）

下面介紹瞭如何在不停止主庫的前提下，爲複製環境新增從庫。大致方法是：複製一個從庫，修改server-id。

大概包括以下步驟：

1.  關閉一個從庫

shell> mysqladmin shutdown

2.  把已有從庫的數據目錄拷貝到新從庫中。方法很多，如cp、rsync、tar、zip。不管什麼方法，記得拷貝的時候包括日誌文件和relay log文件。

增加新從庫時，容易出現新從庫啓動失敗的問題，並出現如下錯誤信息

071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
replication may break when this MySQL server acts as a slave and has his hostname
changed!! Please use '--relay-log=new_slave_hostname-relay-bin' to avoid this problem.
071118 16:44:10 [ERROR] Failed to open the relay log './old_slave_hostname-relay-bin.003525'
(relay_log_pos 22940879)
071118 16:44:10 [ERROR] Could not find target log during relay log initialization
071118 16:44:10 [ERROR] Failed to initialize the master info structure

這是因爲--relay-log參數沒指定（可參見Section 17.1.3, “Replication and Binary Logging Options and Variables”）。要避免這個問題發生，要保證新從庫和舊從庫有相同的--relay-log值。如果舊從庫沒有配這個值，那麼使用existing_slave_hostname-relay-bin。要是這也不行，那就把舊從庫的relay log的索引文件拷過去，並把--relay-log-index選項的值設置爲舊從庫相同的值。（如果舊從庫上也沒有配這個值，那麼使用existing_slave_hostname-relay-bin.index）。如果已經完成了後面的3-6步，啓動新從庫，還碰到錯誤，那麼試試以下步驟：

    a.  使用STOP SLAVE停止新從庫和舊從庫。

    b.  將舊從庫的relay log index文件拷貝到新從庫對應位置。

    c.  執行後面的步驟

3.  將舊從庫的master.info和relay-log.info拷貝到新從庫。

4.  啓動舊從庫。

5.  給新從庫賦一個唯一的server-id。

6.  啓動新從庫。

17.1.1.10 爲從庫配置主庫信息（Setting the Master Configuration on the Slave）

要想從庫與主庫正常通信，必須給從庫足夠的信息。可以用下面這些語句替代配置文件裏的值

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master_host_name',
    ->     MASTER_USER='replication_user_name',
    ->     MASTER_PASSWORD='replication_password',
    ->     MASTER_LOG_FILE='recorded_log_file_name',
    ->     MASTER_LOG_POS=recorded_log_position;

注意：
Unix socket files不支持Replication，只能通過TCP/IP連接到主庫的MySQL

CHANGE MASTER TO還有其他選項。例如可以配置SSL。詳情可參見：Section 13.4.2.1, “CHANGE MASTER TO Syntax”。