建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
近期我們的數(shù)據(jù)庫(kù)團(tuán)隊(duì)對(duì)原生復(fù)制的多個(gè)方面進(jìn)行了深度優(yōu)化，提升了UDB高可用數(shù)據(jù)庫(kù)的功能和性能。今天借社群這個(gè)平臺(tái)，跟大家分享一二。
創(chuàng)新互聯(lián)建站主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)寶山,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢(xún)建站服務(wù):028-86922220
一、UDB高可用數(shù)據(jù)庫(kù)架構(gòu)
- UDB以虛擬IP、HAProxy、單節(jié)點(diǎn)UDB數(shù)據(jù)庫(kù)搭建雙節(jié)點(diǎn)高可用架構(gòu)：
- 雙節(jié)點(diǎn)的UDB數(shù)據(jù)庫(kù)保證數(shù)據(jù)庫(kù)數(shù)據(jù)的全量冗余，同時(shí)保證數(shù)據(jù)庫(kù)的可用性;
- HAProxy在同一時(shí)間只連接一個(gè)UDB節(jié)點(diǎn)，避免多點(diǎn)寫(xiě)入帶來(lái)的數(shù)據(jù)沖突問(wèn)題;
- 雙節(jié)點(diǎn)HAProxy保證Proxy的可用性;
虛擬IP在HAProxy發(fā)生宕機(jī)時(shí)通過(guò)IP漂移的方式對(duì)HAProxy進(jìn)行切換，用戶(hù)不需要再次修改IP。
在上述架構(gòu)中，從節(jié)點(diǎn)UDB的數(shù)據(jù)是否完整、是否與主庫(kù)保證數(shù)據(jù)一致性是整個(gè)高可用架構(gòu)的關(guān)鍵，所以用于數(shù)據(jù)傳輸?shù)陌胪綇?fù)制起著至關(guān)重要的作用。針對(duì)原生的半同步復(fù)制，我們作了內(nèi)核層面的深度優(yōu)化。
二、UDB數(shù)據(jù)庫(kù)深度優(yōu)化
UDB是以開(kāi)源數(shù)據(jù)庫(kù)MySQL Community Server 5.7.16為基線版本，圍繞高可用架構(gòu)做內(nèi)核深度優(yōu)化。
復(fù)制流程，如上圖所示，主要經(jīng)過(guò)如下幾個(gè)步驟：
- MySQL Server執(zhí)行SQL成功后，記錄binlog;
- Dump線程讀取binlog后，發(fā)送到從機(jī)IO線程;
- IO線程將接收到的binlog記錄到relay log中，同時(shí)記錄接收進(jìn)度到master.info中;
- SQL讀取relay log中的日志內(nèi)容進(jìn)行復(fù)現(xiàn)，同時(shí)記錄復(fù)制日志的進(jìn)度到relay-log.info中。
我們?cè)谠鷱?fù)制的基礎(chǔ)上做了內(nèi)核的深度優(yōu)化，針對(duì)上述流程中的部分步驟，在功能和性能上做了改進(jìn)，使得 UDB更加穩(wěn)定。
1、Binlog日志復(fù)制優(yōu)化
存在的問(wèn)題
原生半同步復(fù)制存在退化問(wèn)題，在網(wǎng)絡(luò)抖動(dòng)導(dǎo)致超時(shí)或者從庫(kù)追趕主庫(kù)日志進(jìn)度時(shí)，復(fù)制會(huì)由半同步復(fù)制退化為異步復(fù)制。
相比于可靠的半同步復(fù)制，異步復(fù)制過(guò)程中，從庫(kù)是沒(méi)有辦法感知接收到relay log與主庫(kù)的binlog是否一致。如果發(fā)生宕機(jī)，也就沒(méi)有辦法確認(rèn)從庫(kù)數(shù)據(jù)是否與主庫(kù)一致，是否可以發(fā)生數(shù)據(jù)庫(kù)切換，這種不確定的情況是我們不希望看到的。
優(yōu)化方案
建立雙通道復(fù)制，在原有半同步復(fù)制的基礎(chǔ)上增加一條UDB復(fù)制通道：
- 建立一條新的復(fù)制通道與原有的復(fù)制并行，兩條通道互相獨(dú)立;
- 新的復(fù)制通道不傳輸數(shù)據(jù)，只傳輸主庫(kù)的SQL執(zhí)行進(jìn)度 (binlog的文件名和位置);
- 新的復(fù)制通道使用半同步復(fù)制協(xié)議，但是不退化，超時(shí)后重連，只接收***的SQL執(zhí)行進(jìn)度 ;
- 新的復(fù)制通道不存在追補(bǔ)數(shù)據(jù)的問(wèn)題，只要網(wǎng)絡(luò)正常的情況下，從庫(kù)永遠(yuǎn)可以感知SQL的執(zhí)行進(jìn)度。
如上圖所示，當(dāng)從庫(kù)發(fā)生宕機(jī)或者網(wǎng)絡(luò)發(fā)生故障后，主從復(fù)制停止。當(dāng)從庫(kù)復(fù)制恢復(fù)正常后，原生復(fù)制通道通過(guò)異步復(fù)制的方式進(jìn)行數(shù)據(jù)追補(bǔ)，UDB復(fù)制通道只接收***的binlog記錄位置，這樣可以***限度地減少主從之間異步復(fù)制的時(shí)間。即在網(wǎng)絡(luò)可連通的情況下，無(wú)論何時(shí)發(fā)生宕機(jī)，從庫(kù)均知道與主庫(kù)是否處于數(shù)據(jù)一致的狀態(tài)(或者落后了多少)。
2、Relay log文件記錄的優(yōu)化
存在的問(wèn)題
在MySQL中，binlog是以event為基本單位進(jìn)行記錄，以MySQL 5.7 ROW格式(開(kāi)啟GTID)的binlog為例，一個(gè)DML(insert)會(huì)以5個(gè)event的格式記錄到binlog中(其他操作均以一個(gè)或者多個(gè)event組成，不再一一羅列)，分別為：
- GTID_EVENT：記錄當(dāng)前事務(wù)的GTID
- QUERY_EVENT：事務(wù)開(kāi)始
- TABLE_MAP_EVENT：操作對(duì)應(yīng)的表
- WRITE_ROW_EVENT：插入記錄
- XID_EVENT：提交事務(wù)
全部event組成一個(gè)完整的事務(wù)，完整的事務(wù)才會(huì)被SQL線程正確復(fù)現(xiàn)到從庫(kù)上。當(dāng)前IO線程接收binlog時(shí)，是以event為單位進(jìn)行接收，即接收到一個(gè)event，記錄到relay log中后再繼續(xù)接收下一個(gè)。這種做法是低效的，也沒(méi)有充分利用到MySQL本身的文件緩存。
優(yōu)化方案
優(yōu)化IO線程記錄relay log的方式，將以event為單位記錄，修改為以事務(wù)為單位進(jìn)行記錄。合并IO線程小的IO操作，提高IO性能。
將單個(gè)的event寫(xiě)操作合并為多個(gè)event統(tǒng)一寫(xiě)操作，將小的IO操作合并成較大的IO操作，提高IO性能。
3、Master.info文件記錄的優(yōu)化
存在的問(wèn)題
Master.info文件在搭建復(fù)制時(shí)，記錄主庫(kù)IP、PORT等連接主庫(kù)的相關(guān)信息，在復(fù)制過(guò)程中，記錄IO線程從主庫(kù)接收到的binlog的文件名和位置，文件和位置會(huì)在每次記錄relay log成功后更新。
在基于GTID搭建復(fù)制后，master.info中記錄的binlog文件和位置不再作為復(fù)制的依據(jù)，所以master.info中記錄的binlog的文件和位置不再是有效的數(shù)據(jù)，也就沒(méi)有必要每次進(jìn)行更新。
優(yōu)化方案
在IO線程記錄relay log成功后，更新master.info文件之前，添加判斷。如果開(kāi)啟了GTID并且使用GTID作為復(fù)制的依據(jù)(auto_position=1)，那么不再更新master.info中binlog的文件和位置。
其它的master.info操作仍然保留，如change master、shutdown等操作。
4、Relay log鎖的優(yōu)化
存在的問(wèn)題
在IO線程和SQL線程復(fù)制進(jìn)度相似的情況下，在操作relay log時(shí)，會(huì)使用同一塊文件緩存，在讀寫(xiě)文件緩存時(shí)，需要加鎖來(lái)保證操作的正確性。而IO線程和SQL線程需要頻繁地讀寫(xiě)這塊公共內(nèi)存，就需要對(duì)同一把鎖頻繁的競(jìng)爭(zhēng)，從而導(dǎo)致性能下降。
優(yōu)化方案
將IO線程和SQL線程對(duì)relay log的操作拆分開(kāi)來(lái)，不再使用同一塊文件緩存。雖然這樣做會(huì)導(dǎo)致SQL線程增加一次讀IO操作。但是消除了對(duì)鎖的競(jìng)爭(zhēng)，大大地提高了IO線程和SQL線程整體的性能。
三、總結(jié)
優(yōu)化后的復(fù)制流程圖如下：
數(shù)據(jù)庫(kù)原生復(fù)制流程中包括記錄binlog、記錄relay log、記錄master.info、relay-log.info等，針對(duì)上述流程中的部分步驟以及其它未列出的優(yōu)化，在功能和性能上進(jìn)行改進(jìn)，UDB高可用數(shù)據(jù)庫(kù)在功能和性能上均得到了明顯的提升。
本文名稱(chēng)：MySQL高可用數(shù)據(jù)庫(kù)內(nèi)核深度優(yōu)化的四重定制
文章起源：http://m.5511xx.com/article/dhhjcgj.html
