共計 2871 個字符，預計需要花費 8 分鐘才能閱讀完成。
這篇文章主要介紹 MySQL 復制以及調優原理的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
一. 簡介
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.logserver-id 是數據庫在整個數據庫集群中的唯一標示，必須保持唯一。
重啟 MySQL。
注：如果 MySQL 配置文件中已經配置過此文件，則可以跳過此步。
2. 新建復制賬號
在主庫里面新建用于從庫復制主庫數據的賬號，并授予復制權限。
mysql GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO user_name@ host IDENTIFIED BY password3. 設置 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 端口。由于從庫同步主庫的方式，監聽主庫發送的信息，而不是輪詢，因此如果出現通信出現了故障，重新連接后如果主庫沒有進行數據更改的操作，從庫不會同步數據，因此可以通過插入空事務的方式同步數據。
以上是“MySQL 復制以及調優原理的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！
