主從復(fù)制是怎么實(shí)現(xiàn)的呢？更新語(yǔ)句會(huì)記錄 binlog，它是一種邏輯日志。
有了這個(gè) binlog，從服務(wù)器會(huì)獲取主服務(wù)器的 binlog 文件，然后解析里面的 SQL 語(yǔ)句，在從服務(wù)器上面執(zhí)行一遍，保持主從的數(shù)據(jù)一致。
這里面涉及到三個(gè)線程，連接到 master 獲取 binlog，并且解析 binlog 寫入中繼日 志，這個(gè)線程叫做 I/O 線程。
Master 節(jié)點(diǎn)上有一個(gè) log dump 線程，是用來(lái)發(fā)送 binlog 給 slave 的。
從庫(kù)的 SQL 線程，是用來(lái)讀取 relay log，把數(shù)據(jù)寫入到數(shù)據(jù)庫(kù)的。
做了主從復(fù)制的方案之后，我們只把數(shù)據(jù)寫入 master 節(jié)點(diǎn)，而讀的請(qǐng)求可以分擔(dān)到 slave 節(jié)點(diǎn)。我們把這種方案叫做讀寫分離。
讀寫分離可以一定程度低減輕數(shù)據(jù)庫(kù)服務(wù)器的訪問壓力，但是需要特別注意主從數(shù) 據(jù)一致性的問題。如果我們?cè)?master 寫入了，馬上到 slave 查詢，而這個(gè)時(shí)候 slave 的 數(shù)據(jù)還沒有同步過來(lái)，怎么辦？ 所以，基于主從復(fù)制的原理，我們需要弄明白，主從復(fù)制到底慢在哪里？
單線程
在早期的 MySQL 中，slave 的 SQL 線程是單線程。master 可以支持 SQL 語(yǔ)句的并 行執(zhí)行，配置了多少的最大連接數(shù)就是最多同時(shí)多少個(gè) SQL 并行執(zhí)行。
而 slave 的 SQL 卻只能單線程排隊(duì)執(zhí)行，在主庫(kù)并發(fā)量很大的情況下，同步數(shù)據(jù)肯 定會(huì)出現(xiàn)延遲
為什么從庫(kù)上的 SQL Thread 不能并行執(zhí)行呢？舉個(gè)例子，主庫(kù)執(zhí)行了多條 SQL 語(yǔ) 句，首先用戶發(fā)表了一條評(píng)論，然后修改了內(nèi)容，最后把這條評(píng)論刪除了。這三條語(yǔ)句 在從庫(kù)上的執(zhí)行順序肯定是不能顛倒的
insert into user_comments (10000009,'nice');
update user_comments set content ='very good' where id =10000009;
delete from user_comments where id =10000009;
怎么解決這個(gè)問題呢？怎么減少主從復(fù)制的延遲？
異步與全同步
首先我們需要知道，在主從復(fù)制的過程中，MySQL 默認(rèn)是異步復(fù)制的。也就是說， 對(duì)于主節(jié)點(diǎn)來(lái)說，寫入 binlog，事務(wù)結(jié)束，就返回給客戶端了。對(duì)于 slave 來(lái)說，接收 到 binlog，就完事兒了，master 不關(guān)心 slave 的數(shù)據(jù)有沒有寫入成功。
如果要減少延遲，是不是可以等待全部從庫(kù)的事務(wù)執(zhí)行完畢，才返回給客戶端呢？ 這樣的方式叫做
全同步復(fù)制。從庫(kù)寫完數(shù)據(jù)，主庫(kù)才返會(huì)給客戶端。
這種方式雖然可以保證在讀之前，數(shù)據(jù)已經(jīng)同步成功了，但是帶來(lái)的副作用大家應(yīng) 該能想到，事務(wù)執(zhí)行的時(shí)間會(huì)變長(zhǎng)，它會(huì)導(dǎo)致 master 節(jié)點(diǎn)性能下降。
有沒有更好的辦法呢？既減少 slave 寫入的延遲，又不會(huì)明顯增加 master 返回給客 戶端的時(shí)間？
半同步復(fù)制
介于異步復(fù)制和全同步復(fù)制之間，還有一種半同步復(fù)制的方式。
主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個(gè)從庫(kù) 接收到 binlog 并寫到 relay log 中才返回給客戶端。master 不會(huì)等待很長(zhǎng)的時(shí)間，但是 返回給客戶端的時(shí)候，數(shù)據(jù)就即將寫入成功了，因?yàn)樗皇Ｗ詈笠徊搅耍壕褪亲x取 relay log，寫入從庫(kù)。
如果我們要在數(shù)據(jù)庫(kù)里面用半同步復(fù)制，必須安裝一個(gè)插件，這個(gè)是谷歌的一位工 程師貢獻(xiàn)的。這個(gè)插件在 mysql 的插件目錄下已經(jīng)有提供：
cd /usr/lib64/mysql/plugin/
主庫(kù)和從庫(kù)是不同的插件，安裝之后需要啟用：
-- 主庫(kù)執(zhí)行
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
set global rpl_semi_sync_master_enabled=1;
show variables like '%semi_sync%';
-- 從庫(kù)執(zhí)行
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
set global rpl_semi_sync_slave_enabled=1;
show global variables like '%semi%';
相對(duì)于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，同時(shí)它也造成了一定程度的延 遲，它需要等待一個(gè) slave 寫入中繼日志，這里多了一個(gè)網(wǎng)絡(luò)交互的過程，所以，半同步 復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用。
這個(gè)是從主庫(kù)和從庫(kù)連接的角度，來(lái)保證 slave 數(shù)據(jù)的寫入。
另一個(gè)思路，如果要減少主從同步的延遲，減少 SQL 執(zhí)行造成的等待的時(shí)間，那有 沒有辦法在從庫(kù)上，讓多個(gè) SQL 語(yǔ)句可以并行執(zhí)行，而不是排隊(duì)執(zhí)行呢？
多庫(kù)并行復(fù)制
怎么實(shí)現(xiàn)并行復(fù)制呢？設(shè)想一下，如果 3 條語(yǔ)句是在三個(gè)數(shù)據(jù)庫(kù)執(zhí)行，操作各自的 數(shù)據(jù)庫(kù)，是不是肯定不會(huì)產(chǎn)生并發(fā)的問題呢？執(zhí)行的順序也沒有要求。當(dāng)然是，所以如 果是操作三個(gè)數(shù)據(jù)庫(kù)，這三個(gè)數(shù)據(jù)庫(kù)的從庫(kù)的 SQL 線程可以并發(fā)執(zhí)行。這是 MySQL 5.6 版本里面支持的多庫(kù)并行復(fù)制。
但是在大部分的情況下，我們都是單庫(kù)多表的情況，在一個(gè)數(shù)據(jù)庫(kù)里面怎么實(shí)現(xiàn)并 行復(fù)制呢？或者說，我們知道，數(shù)據(jù)庫(kù)本身就是支持多個(gè)事務(wù)同時(shí)操作的；為什么這些 事務(wù)在主庫(kù)上面可以并行執(zhí)行，卻不會(huì)出現(xiàn)問題呢？
因?yàn)樗麄儽旧砭褪腔ハ嗖桓蓴_的，比如這些事務(wù)是操作不同的表，或者操作不同的 行，不存在資源的競(jìng)爭(zhēng)和數(shù)據(jù)的干擾。那在主庫(kù)上并行執(zhí)行的事務(wù)，在從庫(kù)上肯定也是 可以并行執(zhí)行，是不是？比如在 master 上有三個(gè)事務(wù)同時(shí)分別操作三張表，這三個(gè)事務(wù) 是不是在 slave 上面也可以并行執(zhí)行呢？
5 異步復(fù)制之 GTID 復(fù)制
https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html
所以，我們可以把那些在主庫(kù)上并行執(zhí)行的事務(wù)，分為一個(gè)組，并且給他們編號(hào)， 這一個(gè)組的事務(wù)在從庫(kù)上面也可以并行執(zhí)行。這個(gè)編號(hào)，我們把它叫做 GTID（Global Transaction Identifiers），這種主從復(fù)制的方式，我們把它叫做基于 GTID 的復(fù)制。
如果我們要使用 GTID 復(fù)制，我們可以通過修改配置參數(shù)打開它，默認(rèn)是關(guān)閉的：
show global variables like 'gtid_mode';
無(wú)論是優(yōu)化 master 和 slave 的連接方式，還是讓從庫(kù)可以并行執(zhí)行 SQL，都是從數(shù) 據(jù)庫(kù)的層面去解決主從復(fù)制延遲的問題。
——學(xué)自咕泡學(xué)院
