《MySQL高可用數(shù)據(jù)庫內(nèi)核深度優(yōu)化的四重定制》要點：
本文介紹了MySQL高可用數(shù)據(jù)庫內(nèi)核深度優(yōu)化的四重定制，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者介紹

王松磊,現(xiàn)任職于UCloud,從事MySQL數(shù)據(jù)庫內(nèi)核研發(fā)工作.主要負(fù)責(zé)UCloud云數(shù)據(jù)庫UDB的內(nèi)核故障排查工作以及數(shù)據(jù)庫新特性的研發(fā)工作.

近期我們的數(shù)據(jù)庫團隊對原生復(fù)制的多個方面進(jìn)行了深度優(yōu)化,提升了UDB高可用數(shù)據(jù)庫的功能和性能.今天借社群這個平臺,跟大家分享一二.

一、UDB高可用數(shù)據(jù)庫架構(gòu)

UDB以虛擬IP、HAProxy、單節(jié)點UDB數(shù)據(jù)庫搭建雙節(jié)點高可用架構(gòu)：

• 雙節(jié)點的UDB數(shù)據(jù)庫保證數(shù)據(jù)庫數(shù)據(jù)的全量冗余,同時保證數(shù)據(jù)庫的可用性；
• HAProxy在同一時間只連接一個UDB節(jié)點,避免多點寫入帶來的數(shù)據(jù)沖突問題；
• 雙節(jié)點HAProxy保證Proxy的可用性；
• 虛擬IP在HAProxy發(fā)生宕機時通過IP漂移的方式對HAProxy進(jìn)行切換,用戶不需要再次修改IP.

在上述架構(gòu)中,從節(jié)點UDB的數(shù)據(jù)是否完整、是否與主庫保證數(shù)據(jù)一致性是整個高可用架構(gòu)的關(guān)鍵,所以用于數(shù)據(jù)傳輸?shù)陌胪綇?fù)制起著至關(guān)重要的作用.針對原生的半同步復(fù)制,我們作了內(nèi)核層面的深度優(yōu)化.

二、UDB數(shù)據(jù)庫深度優(yōu)化

UDB是以開源數(shù)據(jù)庫MySQL Community Server 5.7.16為基線版本,圍繞高可用架構(gòu)做內(nèi)核深度優(yōu)化.

復(fù)制流程,如上圖所示,主要經(jīng)過如下幾個步驟：

• MySQL Server執(zhí)行SQL成功后,記錄binlog；
• Dump線程讀取binlog后,發(fā)送到從機IO線程；
• IO線程將接收到的binlog記錄到relay log中,同時記錄接收進(jìn)度到master.info中；
• SQL讀取relay log中的日志內(nèi)容進(jìn)行復(fù)現(xiàn),同時記錄復(fù)制日志的進(jìn)度到relay-log.info中.

我們在原生復(fù)制的基礎(chǔ)上做了內(nèi)核的深度優(yōu)化,針對上述流程中的部分步驟,在功能和性能上做了改進(jìn),使得 UDB更加穩(wěn)定.

1、Binlog日志復(fù)制優(yōu)化

存在的問題

原生半同步復(fù)制存在退化問題,在網(wǎng)絡(luò)抖動導(dǎo)致超時或者從庫追趕主庫日志進(jìn)度時,復(fù)制會由半同步復(fù)制退化為異步復(fù)制.

相比于可靠的半同步復(fù)制,異步復(fù)制過程中,從庫是沒有辦法感知接收到relay log與主庫的binlog是否一致.如果發(fā)生宕機,也就沒有辦法確認(rèn)從庫數(shù)據(jù)是否與主庫一致,是否可以發(fā)生數(shù)據(jù)庫切換,這種不確定的情況是我們不希望看到的.

優(yōu)化方案

建立雙通道復(fù)制,在原有半同步復(fù)制的基礎(chǔ)上增加一條UDB復(fù)制通道：

• 建立一條新的復(fù)制通道與原有的復(fù)制并行,兩條通道互相獨立；
• 新的復(fù)制通道不傳輸數(shù)據(jù),只傳輸主庫的SQL執(zhí)行進(jìn)度 (binlog的文件名和位置)；
• 新的復(fù)制通道使用半同步復(fù)制協(xié)議,但是不退化,超時后重連,只接收最新的SQL執(zhí)行進(jìn)度 ；
• 新的復(fù)制通道不存在追補數(shù)據(jù)的問題,只要網(wǎng)絡(luò)正常的情況下,從庫永遠(yuǎn)可以感知SQL的執(zhí)行進(jìn)度.

如上圖所示,當(dāng)從庫發(fā)生宕機或者網(wǎng)絡(luò)發(fā)生故障后,主從復(fù)制停止.當(dāng)從庫復(fù)制恢復(fù)正常后,原生復(fù)制通道通過異步復(fù)制的方式進(jìn)行數(shù)據(jù)追補,UDB復(fù)制通道只接收最新的binlog記錄位置,這樣可以最大限度地減少主從之間異步復(fù)制的時間.即在網(wǎng)絡(luò)可連通的情況下,無論何時發(fā)生宕機,從庫均知道與主庫是否處于數(shù)據(jù)一致的狀態(tài)(或者落后了多少).

2、Relay log文件記錄的優(yōu)化

存在的問題

在MySQL中,binlog是以event為基本單位進(jìn)行記錄,以MySQL 5.7 ROW格式(開啟GTID)的binlog為例,一個DML(insert)會以5個event的格式記錄到binlog中(其他操作均以一個或者多個event組成,不再一一羅列),分別為：

• GTID_EVENT：記錄當(dāng)前事務(wù)的GTID
• QUERY_EVENT：事務(wù)開始
• TABLE_MAP_EVENT：操作對應(yīng)的表
• WRITE_ROW_EVENT：插入記錄
• XID_EVENT：提交事務(wù)

全部event組成一個完整的事務(wù),完整的事務(wù)才會被SQL線程正確復(fù)現(xiàn)到從庫上.當(dāng)前IO線程接收binlog時,是以event為單位進(jìn)行接收,即接收到一個event,記錄到relay log中后再繼續(xù)接收下一個.這種做法是低效的,也沒有充分利用到MySQL本身的文件緩存.

優(yōu)化方案

優(yōu)化IO線程記錄relay log的方式,將以event為單位記錄,修改為以事務(wù)為單位進(jìn)行記錄.合并IO線程小的IO操作,提高IO性能.

將單個的event寫操作合并為多個event統(tǒng)一寫操作,將小的IO操作合并成較大的IO操作,提高IO性能.

3、Master.info文件記錄的優(yōu)化

存在的問題

Master.info文件在搭建復(fù)制時,記錄主庫IP、PORT等連接主庫的相關(guān)信息,在復(fù)制過程中,記錄IO線程從主庫接收到的binlog的文件名和位置,文件和位置會在每次記錄relay log成功后更新.

在基于GTID搭建復(fù)制后,master.info中記錄的binlog文件和位置不再作為復(fù)制的依據(jù),所以master.info中記錄的binlog的文件和位置不再是有效的數(shù)據(jù),也就沒有必要每次進(jìn)行更新.

優(yōu)化方案

在IO線程記錄relay log成功后,更新master.info文件之前,添加判斷.如果開啟了GTID并且使用GTID作為復(fù)制的依據(jù)(auto_position=1),那么不再更新master.info中binlog的文件和位置.

其它的master.info操作仍然保留,如change master、shutdown等操作.

4、Relay log鎖的優(yōu)化

存在的問題

在IO線程和SQL線程復(fù)制進(jìn)度相似的情況下,在操作relay log時,會使用同一塊文件緩存,在讀寫文件緩存時,需要加鎖來保證操作的正確性.而IO線程和SQL線程需要頻繁地讀寫這塊公共內(nèi)存,就需要對同一把鎖頻繁的競爭,從而導(dǎo)致性能下降.

優(yōu)化方案

將IO線程和SQL線程對relay log的操作拆分開來,不再使用同一塊文件緩存.雖然這樣做會導(dǎo)致SQL線程增加一次讀IO操作.但是消除了對鎖的競爭,大大地提高了IO線程和SQL線程整體的性能.

三、總結(jié)

優(yōu)化后的復(fù)制流程圖如下：

數(shù)據(jù)庫原生復(fù)制流程中包括記錄binlog、記錄relay log、記錄master.info、relay-log.info等,針對上述流程中的部分步驟以及其它未列出的優(yōu)化,在功能和性能上進(jìn)行改進(jìn),UDB高可用數(shù)據(jù)庫在功能和性能上均得到了明顯的提升.

文章來自微信公眾號：DBAplus社群

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/1964.html