一. 簡介

MySQL自帶複製方案，帶來好處有：

資料備份。

負載均衡。

分散式資料。

概念介紹：

主機（master）：被複制的資料庫。

從機（slave）：複製主機資料的資料庫。

複製步驟：
(1). master記錄更改的明細，存入到二進位制日誌（binary log）。
(2). master傳送同步訊息給slave。
(3). slave收到訊息後，將master的二進位制日誌複製到本地的中繼日誌（relay log）。
(4). slave重現中繼日誌中的訊息，從而改變資料庫的資料。

下面放一張經典的圖片來說明這一過程：

二. 實現複製

實現複製有以下步驟：

1.設定MySQL主庫的二進位制日誌以及server-id

MySQL配置檔案一般存放在/etc/my.cnf

# 在[mysqld]下面新增配置選項
[mysqld]
server-id=1
log-bin=mysql-bin.log

server-id是資料庫在整個資料庫叢集中的唯一標示，必須保持唯一。
重啟MySQL。

注：如果MySQL配置檔案中已經配置過此檔案，則可以跳過此步。

2.新建複製賬號

在主庫裡面新建用於從庫複製主庫資料的賬號，並授予複製許可權。

mysql> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO user_name@'host' IDENTIFIED BY 'password';

3.設定MySQL主庫server-id

和第二步配置一樣，要注意的地方有兩點：

如果不需要從庫作為別的從庫的主庫的話，則不需要配置二進位制日誌。很多時候複製並不需要複製主庫的全部資料庫（特別是mysql的資訊配置庫）。因此可以配置replicate_do_db來指定複製的資料庫 4.從庫初始化主庫的資料

如果資料量不算大的情況下，可以使用mysqldump工具匯出主庫資料，然後匯入到從庫裡面。

mysqldump --single-transaction --triggers --master-data databasename > data.sql

如果資料量大的情況下應該使用Xtrabackup去進行資料庫的匯出，此處不做介紹。

如果我們主庫運行了比較長的一段時間，並不太適合使用從庫根據二進位制日誌進行復制資料，直接使用二進位制日誌去初始化從庫會比較耗費時間和效能。更多的情況下，主庫的二進位制日誌的配置項沒有開啟，因此也就不存在以前操作的二進位制日誌。 5.開啟複製

從庫執行下面命令

mysql> CHANGE MASTER TO MASTER_HOST='host',-> MASTER_USER='user',-> MASTER_PASSWORD='password',-> MASTER_LOG_FILE='mysql-bin.000001',-> MASTER_LOG_POS=0;

注意最後的兩個命令：MASTER_LOG_FILE和MASTER_LOG_POS，表示從庫的從哪個二進位制檔案開始讀取，偏移量從那裡開始，這兩個引數可以從我們匯入的SQL裡面找到。

開啟複製

start slave;

這時候就完成了複製，在主庫更新一個數據或者新增資料在從庫都可以查詢到結果。

在主庫上也可以查詢的到複製執行緒的狀態。

三. 複製的日誌格式

MySQL複製的日誌格式有三種，根據主庫存放資料的方式不同有以下三種：

複製方式	特點	優點	缺點
row	基於行的格式複製，記錄需要修改的每行的資料資訊。 如果一個SQL修改了2w行的資料，那麼就會記錄2w行的日誌格式	保證了資料的強一致性，且由於記錄的是執行後的結果，在從庫上執行還原也會比較快	日誌記錄數量很多，主從之間的傳輸需要更多的時間。
statement	基於段的日誌格式複製，也就是記錄下更改的SQL記錄，而不是更改的行的記錄。	日誌記錄量最小。	對於一些輸出結果不確定的函式，在從庫上執行一遍很可能會出現問題，如uuid，從庫根據日誌還原主庫資料的時候需要執行一遍SQL，時間相對較慢。
mixed	混合上面兩種日誌格式記錄記錄日誌，至於什麼時候使用哪種日誌方式由MySQL本身決定。	可以平衡上面兩種日誌格式的優缺點。

mysql5.7以前預設使用statement格式。

設定方式，可以在配置檔案設定（首選）：

binlog_format=ROW

或臨時設定全域性變數（當前mysql連線有效）：

檢視日誌格式
mysql > show variables like 'binlog_format';
設定日誌格式
mysql > set binlog_format='row';

由於兩個主從伺服器一般都會放在同一個機房裡面，兩者之間同步的速度會會比較快，為保證強一致性，應該首選行的日誌格式記錄（row），保證傳輸素速度可以選擇混合方式（mixed）。
而行的日誌格式有下面三種記錄方式：

記錄方式	特點
minimal	只記錄被修改列的資料
full	記錄被修改的行的全部列的資料
noblob	特點同上，只是如果沒有修改blob和text型別的列的情況下，不會記錄這些列的資料（也就是大資料列）

mysql預設是full，最好修改成minimal。

binlog_row_image=minimal

四. 主從複製延遲

由於主庫和從庫之間不在同一個主機上，資料同步之間不可以避免地具有延遲，解決的方法有新增快取，業務層的跳轉等待，如果非得從資料庫層面去減緩延遲問題，可以從複製時候的三大步驟（主庫產生日誌，主從傳輸日誌，從庫還原日誌內容）入手：

1.主庫寫入到日誌的速度

控制主庫的事務大小，分割大事務為多個小事務。

如插入20w的資料，改成插入多次5000行（可以利用分頁的思路）

2.二進位制日誌在主從之間傳輸時間

主從之間儘量在同一個機房或地域。

日誌格式改用MIXED，且設定行的日誌格式未minimal，原理詳見上面的日誌格式介紹。

3.減少從庫還原日誌的時間

在MySQL5.7版本後可以利用邏輯時鐘方式分配SQL多執行緒。

設定邏輯時鐘：slave_parallel_type=‘logical_clock';

設定複製執行緒個數：slave_parallel_workers=4;

五. 需要注意的地方

重啟MySQL最好切換未MySQL使用者再進行操作，不然檔案啟動後會有許可權問題。搭建好MySQL的環境後就設定好配置裡的log-bin選項，這樣以後如果資料庫需要從庫的複製，就不需要重啟資料庫，打斷業務的進行。需要開啟主庫的防火牆的對應的mysql埠。由於從庫同步主庫的方式，監聽主庫傳送的資訊，而不是輪詢，因此如果出現通訊出現了故障，重新連線後如果主庫沒有進行資料更改的操作，從庫不會同步資料，因此可以通過插入空事務的方式同步資料。

以上就是小編本次整理的全部內容，感謝你對我們的支援。