目錄
- 一主多從復(fù)制架構(gòu)
- 多級(jí)復(fù)制架構(gòu)
- 雙主(Dual Master)復(fù)制架構(gòu)
- 多源(Multi-Source)復(fù)制架構(gòu)
- 如何優(yōu)化主從延遲問(wèn)題?
復(fù)制的4中常見(jiàn)架構(gòu)有一主多從復(fù)制架構(gòu)、多級(jí)復(fù)制架構(gòu)、雙主(Dual Master)復(fù)制架構(gòu)和多源(Multi-Source)復(fù)制架構(gòu)。
一主多從復(fù)制架構(gòu)
在主庫(kù)讀取請(qǐng)求壓力非常大的場(chǎng)景下,可以通過(guò)配置一主多從復(fù)制架構(gòu)實(shí)現(xiàn)讀寫(xiě)分離,把大量的對(duì)實(shí)時(shí)性要求不是特別高的讀請(qǐng)求通過(guò)負(fù)載均衡分布到多個(gè)從庫(kù)上(對(duì)于實(shí)時(shí)性要求很高的讀請(qǐng)求可以讓從主庫(kù)去讀),降低主庫(kù)的讀取壓力,如下圖所示。
在主庫(kù)出現(xiàn)異常宕機(jī)的情況下,可以把一個(gè)從庫(kù)切換為主庫(kù)繼續(xù)提供服務(wù)。
在主從復(fù)制場(chǎng)景下會(huì)出現(xiàn)主從延遲,想想該怎么解決?
多級(jí)復(fù)制架構(gòu)
一主多從的架構(gòu)能夠解決大部分讀請(qǐng)求壓力特別大的的場(chǎng)景的需求,考慮到MySQL的復(fù)制需要主庫(kù)發(fā)送BINLOG日志到從庫(kù)的I/O線(xiàn)程,主庫(kù)的I/O壓力和網(wǎng)絡(luò)壓力會(huì)隨著從庫(kù)的增加而增長(zhǎng)(每個(gè)從庫(kù)都會(huì)在主庫(kù)上有一個(gè)獨(dú)立的BINLOG Dump線(xiàn)程來(lái)發(fā)送事件),而多級(jí)復(fù)制架構(gòu)解決了一主多從場(chǎng)景下的,主庫(kù)額外的I/O和網(wǎng)絡(luò)壓力。MySQL的多級(jí)復(fù)制架構(gòu)如下圖所示。
對(duì)比一主多從的架構(gòu),多級(jí)復(fù)制僅僅是在主庫(kù)Master1復(fù)制到從庫(kù)Slave1、Slave2、Slave3的中間增加了一個(gè)二級(jí)主庫(kù)Master2,這樣,主庫(kù)Master1只需要給一個(gè)從庫(kù)Master2發(fā)送BINLOG日志即可,減輕了主庫(kù)Master1的壓力。二級(jí)主庫(kù)Master2再發(fā)送BINLOG日志給所有的從庫(kù)Slave1、Slave2和Slave3的I/O線(xiàn)程。
多級(jí)復(fù)制解決了一主多從場(chǎng)景下,主庫(kù)的I/O負(fù)載和網(wǎng)絡(luò)壓力,當(dāng)然也有缺點(diǎn):MySQL的傳統(tǒng)復(fù)制是異步的,多級(jí)復(fù)制場(chǎng)景下主庫(kù)的數(shù)據(jù)是經(jīng)歷兩次復(fù)制才到達(dá)從庫(kù)Slave1、Slave2、Slave3的,期間的延遲要比一主多從復(fù)制場(chǎng)景下只經(jīng)歷一次復(fù)制的還大。
可以通過(guò)在二級(jí)主庫(kù)Master2上選擇表引擎為BLACKHOLE來(lái)降低多級(jí)復(fù)制的延遲。顧名思義,BLACKHOLE引擎是一個(gè)“黑洞”引擎,寫(xiě)入BLACKHOLE表的數(shù)據(jù)并不會(huì)寫(xiě)回到磁盤(pán)上,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表里沒(méi)有數(shù)據(jù)。
BLACKHOLE引擎非常適合二級(jí)主庫(kù)Masger2的場(chǎng)景:Master2并不承擔(dān)讀寫(xiě)請(qǐng)求,僅僅負(fù)責(zé)將BINLOG日志盡快傳送給從庫(kù)。
雙主(Dual Master)復(fù)制架構(gòu)
雙主(Dual Master)復(fù)制架構(gòu)適用于DBA做維護(hù)時(shí)需要主從切換的場(chǎng)景,通過(guò)雙主復(fù)制架構(gòu)避免了重復(fù)搭建從庫(kù)的麻煩,雙主復(fù)制架構(gòu)如下圖所示。
主庫(kù)Master1和Master互為主從,所有Web Client的寫(xiě)請(qǐng)求都訪(fǎng)問(wèn)主庫(kù)Master1或Master2。假如,DBA需要做日常維護(hù)操作,為了避免影響服務(wù),需進(jìn)行一下操作。
- 首先,在Master1庫(kù)上停止Slave線(xiàn)程(STOP SLAVE),避免后續(xù)對(duì)Master2庫(kù)的維護(hù)操作操作被實(shí)時(shí)復(fù)制到Master1庫(kù)上對(duì)服務(wù)造成影響。
- 其次,在Master2庫(kù)上停止Slave線(xiàn)程(STOP SLAVE),開(kāi)始日常維護(hù)操作,例如修改varchar字段從長(zhǎng)度10增加到200。
- 然后,在Master2庫(kù)上完成維護(hù)操作之后,打開(kāi)Master2庫(kù)上的Slave線(xiàn)程(STRART SLAVE),讓Master2的數(shù)據(jù)和Master1庫(kù)同步,同步完成后,把應(yīng)用的寫(xiě)操作切換到Master2庫(kù)上。
- 最后,確認(rèn)Master1庫(kù)上沒(méi)有應(yīng)用訪(fǎng)問(wèn)后,打開(kāi)Master1的Slave線(xiàn)程(START SLAVE)即可。
通過(guò)雙主復(fù)制架構(gòu)能夠大大減輕一主多從架構(gòu)下對(duì)主庫(kù)進(jìn)行維護(hù)帶來(lái)的額外搭建從庫(kù)的工作。
當(dāng)然雙主架構(gòu)還能和主從復(fù)制聯(lián)合起來(lái)使用:在Master2庫(kù)下配置從庫(kù)Slave1、Slave2等,這樣既可通過(guò)從庫(kù)Slave1等來(lái)分擔(dān)讀取壓力,同時(shí)在DBA做維護(hù)的同時(shí),避免了重建從庫(kù)的額外工作,但需要注意從庫(kù)的復(fù)制延遲。MySQL雙主多級(jí)復(fù)制架構(gòu)如下所示。
多源(Multi-Source)復(fù)制架構(gòu)
多源(Multi-Source)復(fù)制架構(gòu)適用于復(fù)雜的業(yè)務(wù)需求,既可以支撐OLTP(聯(lián)機(jī)事務(wù)處理),也可以滿(mǎn)足OLAP(聯(lián)機(jī)分析處理)。MySQL的多源復(fù)制架構(gòu)我就暫時(shí)不畫(huà)啦,等有空再畫(huà)好補(bǔ)充上(畫(huà)圖也是個(gè)體力活呀)。有興趣的可以看《深入淺出MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)、優(yōu)化與管理維護(hù)》這本書(shū)。
如何優(yōu)化主從延遲問(wèn)題?
- 優(yōu)化網(wǎng)絡(luò)環(huán)境
- 在MySQL5.5~MySQL5.6中,使用半同步復(fù)制
- 在MySQL5.7中,可以使用增強(qiáng)半同步復(fù)制(也稱(chēng)為無(wú)損復(fù)制)