1.資料複製概述

1.1資料複製定義

資料複製使一個服務上的資料與另一個服務上資料保持同步

1.2複製用途

• 資料分佈
• 負載均衡
• 備份
• 高可用和故障切換
• MySQL升級測試

2.資料複製工作原理

2.1複製工作流程介紹（以主從架構為例）

MySQL複製原理比較簡單，其核心工作示意圖如下：

• 主庫把更新操作記錄在二進位制日誌檔案中
• 備庫上的I/O執行緒收到主庫的更新事件後，讀取新增的二進位制日誌並寫入自己的中繼日誌中
• 備庫讀取中繼日誌，將事件在資料庫上重放，更新自身資料庫資料

2.2對主從複製架構的思考

看完圖2.1中MySQL主從架構，讀者會不會感覺如果去掉中繼日誌，整個複製流程會更簡單？中繼日誌究竟在複製架構中產生了什麼作用？

如果備庫去掉寫中繼日誌這個流程，那麼備庫每次只需要讀取binlog事件資料，緊接著直接重放sql事件即可。而增加了中繼日誌，不僅增加了流程的複雜性，而且多了一次寫檔案I/O的操作消耗了系統性能

其實中繼日誌對備機而言就是快取事件的buffer而已，其作用就是對備機的倆個核心操作(讀主機二進位制日誌事件、重放事件)進行非同步解耦。試想如果主機執行了一個比較耗時的修改(alter修改表字段等)，如果沒有buffer存在的話，備機只能在執行完這個耗時操作之後才能繼續同步主機上的其他新增二進位制事件，這樣可能會造成很多麻煩(比如在執行耗時操作的過程中主機永久宕機無法恢復，那麼這段時間裡主機新增的大量二進位制日誌，備機將無法重放，造成大量資料丟失，後果嚴重)。

備機寫中繼日誌會有大量I/O操作，會不會影響同步效能呢？正常情況下，中繼日誌的內容都會儲存在系統快取中，所以使用者大可不必擔心

3.資料複製實操

假設如下:

• 主機IP: 192.168.1.1 備機IP: 192.168.1.2
• 主機上MySQL有大量實時資料更新操作(MySQL複製的就是更新操作)

3.1為備機開通複製許可權賬號

GRANT REPLICATION SLAVE ON . TO [email protected]‘192.168.1.2’ IDENTIFIED BY ‘replpwd’;```
在主機上執行上述命令便可為備機建立一個專門用於複製的使用者賬號，賬號名為: repluser、密碼為: replpwd

3.2主機開啟binlog功能

預設的mysql是沒有寫binlog的，需要我們修改配置檔案
在/etc/my.cnf的mysqld配置項中增加如下倆行配置

log_bin=/data/mysql/mysql-bin
server_id=100

配置說明：

• log_bin指明bin_log檔名稱以及路徑(/data/mysql目錄必須存在)
• server_id根據mysql例項不同，給一個其他例項不重複的值即可

配置完成後重啟MySQL服務，此時在MySQL終端執行如下命令檢視開啟bin_log是否生效

show master status;

如圖3.1此時主機bin_log已啟動，當前bin_log檔名為: mysql-bin.000001 Pos為: 154

備機想要複製主機的資料，就必須要知道主機的bin_log檔名是啥，以及主機寫binlog的pos在哪裡

此時如果你在主機上插入一條資料，再次檢視狀態就會發現bin_log pos會發生移動了

3.3配置備機中繼日誌

預設的MySQL是沒中繼日誌的，需要我們修改配置檔案
在/etc/my.cnf的mysqld配置項中增加如下配置

server_id=101
relay_log=/data/mysql/mysql-relay-bin
read_only=1

配置說明：

• server_id根據mysql例項不同，給一個其他例項不重複的值即可(注意100已經被主機用了)
• relay_log指明中繼日誌的名稱(/data/mysql目錄必須存在)
• read_only備機設定為只讀，防止備機寫操作將資料寫髒
  配置完成後重啟MySQL服務即可

3.4同步克隆主機當前資料快照

MySQL同步資料的核心便是保證倆臺機器上主機bin_log任一位置pos之前的資料完全一致

由於主機在開啟bin_log之前已經有好多資料了(這些資料沒有記錄在binlog裡，所以備機通過重放binlog日誌是無法同步到這些資料的)，最常用的方法便是：

• 設定主機為只讀(主機之後便不會有資料更新了)
• 通過mysqldump等工具將當前MySQL資料複製並匯入備機
• 記錄下當前主機的bin_log檔案和pos位置(通過在主機執行show master status獲取)
• 關閉主機的只讀設定

此時備機便有了和主機某個bin_log位置一樣的快照資料

本文將使用一種更為簡單的方式：
只需執行如下命令便可:

mysqldump --single-transaction  --all-databases  --master-data=2 --host 192.168.1.1 -uroot -p > all_data.sql

該方法相較前一種方法省掉了設定只讀，和記錄bin_log檔案及位置等操作，那麼我們如何獲取bin_log的位置資訊呢，其實開啟mysqldump的輸出檔案all_data.sql，我們發現如下注釋內容:

如圖3.2中所示，在從主機dump資料的那個時刻的主機bin_log資訊都記錄在dump的輸出檔案中了，此時我們只需記錄下紅框框住的這倆個值即可

最後將dump輸出檔案匯入資料庫

source all_data.sql;

3.5為備機配置和主機的連線通道以及bin_log資訊

在sql終端執行如下命令

change master to master_host='192.168.1.1',
master_user='repluser',
master_password='replpwd',
master_log_file='mysql-bin.000002',
master_log_pos=698;

變數說明：

• master_host: 主機IP
• master_user: 複製使用者名稱(前文中通過主機分配)
• master_password: 複製的密碼
• master_log_file: bin_log檔名(mysqldump輸出檔案中的註釋內容)
• master_log_pos: 當前bin_log位置(mysqldump輸出檔案中的註釋內容)

此時以為備機配置好了master複製相關引數，接下來只需要在備機執行如下命令，便可跑起來主備複製

start slave;

此時在備機上執行如下命令檢查備機執行情況

show slave status\G;

其中如下倆個指標為Yes，則備機執行正常

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

4.主從一致性

MySQL提供的複製功能並不能保證100%的可靠，一些特殊情況下可能會導致MySQL主從資料發生不一致的情況，此時，我們可以通過一些第三方工具來高效的協助我們應對這樣的Case

• pt-table-checksum: 檢查主從資料庫是否一致
• pt-table-sync: 修復主從資料庫不一致現象

5.總結

MySQL複製功能強大，我們在生產環境中可以依據實際需求，靈活搭建：主從、主主、一主多從等多種複製模式來滿足業務需求