你知道MySQL主從複製的原理嗎？

主從複製是怎麼實現的呢？更新語句會記錄 binlog，它是一種邏輯日誌。有了這個 binlog，從服務器會獲取主服務器的 binlog 文件，然後解析裡面的 SQL 語句，在從服務器上面執行一遍，保持主從的數據一致。

這裡面涉及到三個線程，連接到 master 獲取 binlog，並且解析 binlog 寫入中繼日 志，這個線程叫做 I/O 線程。Master 節點上有一個 log dump 線程，是用來發送 binlog 給 slave 的。從庫的 SQL 線程，是用來讀取 relay log，把數據寫入到數據庫的。

做了主從複製的方案之後，我們只把數據寫入 master 節點，而讀的請求可以分擔到 slave 節點。我們把這種方案叫做讀寫分離。

讀寫分離可以一定程度地減輕數據庫服務器的訪問壓力，但是需要特別注意主從數 據一致性的問題。如果我們在 master 寫入了，馬上到 slave 查詢，而這個時候 slave 的 數據還沒有同步過來，怎麼辦？ 所以，基於主從複製的原理，我們需要弄明白，主從複製到底慢在哪裡？

單線程

在早期的 MySQL 中，slave 的 SQL 線程是單線程。master 可以支持 SQL 語句的並 行執行，配置了多少的最大連接數就是最多同時多少個 SQL 並行執行。而 slave 的 SQL 卻只能單線程排隊執行，在主庫併發量很大的情況下，同步數據肯 定會出現延遲為什麼從庫上的 SQL Thread 不能並行執行呢？舉個例子，主庫執行了多條 SQL 語 句，首先用戶發表了一條評論，然後修改了內容，最後把這條評論刪除了。這三條語句 在從庫上的執行順序肯定是不能顛倒的

<code>insert into user_comments (10000009,'nice'); 
update user_comments set content ='very good' where id =10000009;
 delete from user_comments where id =10000009;
/<code>

怎麼解決這個問題呢？怎麼減少主從複製的延遲？

異步與全同步

首先我們需要知道，在主從複製的過程中，MySQL 默認是異步複製的。也就是說， 對於主節點來說，寫入 binlog，事務結束，就返回給客戶端了。對於 slave 來說，接收 到 binlog，就完事兒了，master 不關心 slave 的數據有沒有寫入成功。

如果要減少延遲，是不是可以等待全部從庫的事務執行完畢，才返回給客戶端呢？ 這樣的方式叫做全同步複製。從庫寫完數據，主庫才返會給客戶端。

這種方式雖然可以保證在讀之前，數據已經同步成功了，但是帶來的副作用大家應 該能想到，事務執行的時間會變長，它會導致 master 節點性能下降。有沒有更好的辦法呢？既減少 slave 寫入的延遲，又不會明顯增加 master 返回給客 戶端的時間？

半同步複製

介於異步複製和全同步複製之間，還有一種半同步複製的方式。主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫 接收到 binlog 並寫到 relay log 中才返回給客戶端。master 不會等待很長的時間，但是 返回給客戶端的時候，數據就即將寫入成功了，因為它只剩最後一步了：就是讀取 relay log，寫入從庫。

如果我們要在數據庫裡面用半同步複製，必須安裝一個插件，這個是谷歌的一位工 程師貢獻的。這個插件在 mysql 的插件目錄下已經有提供：cd /usr/lib64/mysql/plugin/主庫和從庫是不同的插件，安裝之後需要啟用：

<code>-- 主庫執行 
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
set global rpl_semi_sync_master_enabled=1; 
show variables like '%semi_sync%'; 


-- 從庫執行 
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; 
set global rpl_semi_sync_slave_enabled=1; 
show global variables like '%semi%';
/<code>

相對於異步複製，半同步複製提高了數據的安全性，同時它也造成了一定程度的延 遲，它需要等待一個 slave 寫入中繼日誌，這裡多了一個網絡交互的過程，所以，半同步 複製最好在低延時的網絡中使用。

這個是從主庫和從庫連接的角度，來保證 slave 數據的寫入。

另一個思路，如果要減少主從同步的延遲，減少 SQL 執行造成的等待的時間，那有 沒有辦法在從庫上，讓多個 SQL 語句可以並行執行，而不是排隊執行呢？

多庫並行複製

怎麼實現並行複製呢？設想一下，如果 3 條語句是在三個數據庫執行，操作各自的 數據庫，是不是肯定不會產生併發的問題呢？執行的順序也沒有要求。當然是，所以如 果是操作三個數據庫，這三個數據庫的從庫的 SQL 線程可以併發執行。這是 MySQL 5.6 版本里面支持的多庫並行複製。

但是在大部分的情況下，我們都是單庫多表的情況，在一個數據庫裡面怎麼實現並 行復制呢？或者說，我們知道，數據庫本身就是支持多個事務同時操作的；為什麼這些 事務在主庫上面可以並行執行，卻不會出現問題呢？

因為他們本身就是互相不干擾的，比如這些事務是操作不同的表，或者操作不同的 行，不存在資源的競爭和數據的干擾。那在主庫上並行執行的事務，在從庫上肯定也是 可以並行執行，是不是？比如在 master 上有三個事務同時分別操作三張表，這三個事務 是不是在 slave 上面也可以並行執行呢？

5 異步複製之 GTID 複製

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html所以，我們可以把那些在主庫上並行執行的事務，分為一個組，並且給他們編號， 這一個組的事務在從庫上面也可以並行執行。這個編號，我們把它叫做 GTID（Global Transaction Identifiers），這種主從複製的方式，我們把它叫做基於 GTID 的複製。

如果我們要使用 GTID 複製，我們可以通過修改配置參數打開它，默認是關閉的：

<code>show global variables like 'gtid_mode';
/<code> 

無論是優化 master 和 slave 的連接方式，還是讓從庫可以並行執行 SQL，都是從數 據庫的層面去解決主從複製延遲的問題。

原文：https://www.jianshu.com/p/a1ab6be91978