一主多從復(fù)制架構(gòu)

在主庫讀取請求壓力非常大的場景下，可以通過配置一主多從復(fù)制架構(gòu)實(shí)現(xiàn)讀寫分離，把大量的對(duì)實(shí)時(shí)性要求不是特別高的讀請求通過負(fù)載均衡分部到多個(gè)從庫上(對(duì)于實(shí)時(shí)性要求很高的讀請求可以讓從主庫去讀)，降低主庫的讀取壓力，如下圖所示。

在主庫出現(xiàn)異常宕機(jī)的情況下，可以把一個(gè)從庫切換為主庫繼續(xù)提供服務(wù)。

在主從復(fù)制場景下會(huì)出現(xiàn)主從延遲，想想該怎么解決？

多級(jí)復(fù)制架構(gòu)

一主多從的架構(gòu)能夠解決大部分讀請求壓力特別大的的場景的需求，考慮到MySQL的復(fù)制需要主庫發(fā)送BINLOG日志到從庫的I/O線程，主庫的I/O壓力和網(wǎng)絡(luò)壓力會(huì)隨著從庫的增加而增長(每個(gè)從庫都會(huì)在主庫上有一個(gè)獨(dú)立的BINLOG Dump線程來發(fā)送事件)，而多級(jí)復(fù)制架構(gòu)解決了一主多從場景下的，主庫額外的I/O和網(wǎng)絡(luò)壓力。MySQL的多級(jí)復(fù)制架構(gòu)如下圖所示。

對(duì)比一主多從的架構(gòu)，多級(jí)復(fù)制僅僅是在主庫Master1復(fù)制到從庫Slave1、Slave2、Slave3的中間增加了一個(gè)二級(jí)主庫Master2，這樣，主庫Master1只需要給一個(gè)從庫Master2發(fā)送BINLOG日志即可，減輕了主庫Master1的壓力。二級(jí)主庫Master2再發(fā)送BINLOG日志給所有的從庫Slave1、Slave2和Slave3的I/O線程。

多級(jí)復(fù)制解決了一主多從場景下，主庫的I/O負(fù)載和網(wǎng)絡(luò)壓力，當(dāng)然也有缺點(diǎn)：MySQL的傳統(tǒng)復(fù)制是異步的，多級(jí)復(fù)制場景下主庫的數(shù)據(jù)是經(jīng)歷兩次復(fù)制才到達(dá)從庫Slave1、Slave2、Slave3的，期間的延遲要比一主多從復(fù)制場景下只經(jīng)歷一次復(fù)制的還大。

可以通過在二級(jí)主庫Master2上選擇表引擎為BLACKHOLE來降低多級(jí)復(fù)制的延遲。顧名思義，BLACKHOLE引擎是一個(gè)“黑洞”引擎，寫入BLACKHOLE表的數(shù)據(jù)并不會(huì)寫會(huì)到磁盤上，BLACKHOLE表永遠(yuǎn)都是空表，INSERT、UPDATE、DELETE操作僅僅在BINLOG中記錄事件。

CREATE TABLE `user` (`id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,`name` varchar(255) NOT NULL DEFAULT ’’,`age` tinyint unsigned NOT NULL DEFAULT 0)ENGINE=BLACKHOLE charset=utf8mb4;INSERT INTO `user` (`name`,`age`) values('itbsl', '26');SELECT * FROM `user`;

可以看到，存儲(chǔ)引擎為BLACKHOLE的user表里沒有數(shù)據(jù)。

BLACKHOLE引擎非常適合二級(jí)主庫Masger2的場景:Master2并不承擔(dān)讀寫請求，僅僅負(fù)責(zé)將BINLOG日志盡快傳送給從庫。

雙主(Dual Master)復(fù)制架構(gòu)

雙主(Dual Master)復(fù)制架構(gòu)適用于DBA做維護(hù)時(shí)需要主從切換的場景，通過雙主復(fù)制架構(gòu)避免了重復(fù)搭建從庫的麻煩，雙主復(fù)制架構(gòu)如下圖所示。

主庫Master1和Master互為主從，所有Web Client的寫請求都訪問主庫Master1或Master2。加入，DBA需要做日常維護(hù)操作，為了避免影響服務(wù)，需進(jìn)行一下操作。

首先，在Master1庫上停止Slave線程(STOP SLAVE)，避免后續(xù)對(duì)Master2庫的維護(hù)操作操作被實(shí)時(shí)復(fù)制到Master1庫上對(duì)服務(wù)造成影響。 其次，在Master2庫上停止Slave線程(STOP SLAVE)，開始日常維護(hù)操作，例如修改varchar字段從長度10增加到200。 然后，在Master2庫上完成維護(hù)操作之后，打開Master2庫上的Slave線程(STRART SLAVE),讓Master2的數(shù)據(jù)和Master1庫同步，同步完成后，把應(yīng)用的寫操作切換到Master2庫上。 最后，確認(rèn)Master1庫上沒有應(yīng)用訪問后，打開Master1的Slave線程(START SLAVE)即可。

通過雙主復(fù)制架構(gòu)能夠大大減輕一主多從架構(gòu)下對(duì)主庫進(jìn)行維護(hù)帶來的額外搭建從庫的工作。

當(dāng)然雙主架構(gòu)還能和主從復(fù)制聯(lián)合起來使用：在Master2庫下配置從庫Slave1、Slave2等，這樣既可通過從庫Slave1等來分擔(dān)讀取壓力，同時(shí)在DBA做維護(hù)的同時(shí)，避免了重建從庫的額外工作，但需要注意從庫的復(fù)制延遲。MySQL雙主多級(jí)復(fù)制架構(gòu)如下所示。

多源(Multi-Source)復(fù)制架構(gòu)

多源(Multi-Source)復(fù)制架構(gòu)適用于復(fù)雜的業(yè)務(wù)需求，既可以支撐OLTP(聯(lián)機(jī)事務(wù)處理),也可以滿足OLAP(聯(lián)機(jī)分析處理)。MySQL的多源復(fù)制架構(gòu)我就暫時(shí)不畫啦,等有空再畫好補(bǔ)充上(畫圖也是個(gè)體力活呀)。有興趣的可以看《深入淺出MySQL數(shù)據(jù)庫開發(fā)、優(yōu)化與管理維護(hù)》這本書。

如何優(yōu)化主從延遲問題？ 優(yōu)化網(wǎng)絡(luò)環(huán)境 在MySQL5.5~MySQL5.6中，使用半同步復(fù)制 在MySQL5.7中，可以使用增強(qiáng)半同步復(fù)制(也稱為無損復(fù)制)

關(guān)于MySQL主從延遲的具體信息，可以看我的另一篇文章聊聊MySQL主從復(fù)制的幾種復(fù)制方式。

整理自：

《深入淺出MySQL數(shù)據(jù)庫開發(fā)、優(yōu)化與管理維護(hù)》這本書。

以上就是MySQL 4種常用的主從復(fù)制架構(gòu)的詳細(xì)內(nèi)容，更多關(guān)于MySQL 主從復(fù)制架構(gòu)的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！