這篇文章主要講解了“MySQL內(nèi)核的深度優(yōu)化方式”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請(qǐng)大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“MySQL內(nèi)核的深度優(yōu)化方式”吧!
站在用戶的角度思考問題,與客戶深入溝通,找到增城網(wǎng)站設(shè)計(jì)與增城網(wǎng)站推廣的解決方案,憑借多年的經(jīng)驗(yàn),讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合,創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品,建站類型包括:成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊(cè)、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋增城地區(qū)。
由于騰訊云上的DB基本都需要跨園區(qū)災(zāi)備的特性,因此CDB for MySQL的優(yōu)化主要針對(duì)主從DB部署在跨園區(qū)網(wǎng)絡(luò)拓?fù)涞那疤嵯?,重點(diǎn)去解決真實(shí)部署環(huán)境下的性能難題。經(jīng)過分析和調(diào)研,我們將優(yōu)化的思路歸納為:“消除冗余I/O、縮短I/O路徑和避免大鎖競(jìng)爭(zhēng)”。以下是內(nèi)核性能的部分案例:
如上圖所示,在原生MySQL的復(fù)制架構(gòu)中,Master側(cè)通過Dump線程不斷發(fā)送Binlog事件給Slave的I/O線程,Slave的I/O線程在接受到Binlog事件后,有兩個(gè)主要的動(dòng)作:
寫入到Relay Log中,這個(gè)過程會(huì)和Slave SQL線程爭(zhēng)搶保護(hù)Relay Log的鎖。
更新復(fù)制元數(shù)據(jù)(包含Master的位置等信息)。
經(jīng)過分析,我們的優(yōu)化策略是:
Slave I/O線程和Slave SQL線程是典型的單寫單讀生產(chǎn)者-消費(fèi)者模型,是可以做到無鎖設(shè)計(jì)的;因此實(shí)現(xiàn)思路就是Slave I/O線程在每次寫完數(shù)據(jù)后,原子更新Relay Log的長度信息,Slave SQL線程讀取Relay Log的時(shí)以長度信息為邊界。這樣就將原本競(jìng)爭(zhēng)激烈的Relay Log鎖化解為無鎖;
由于Binlog事件中的GTID(Global Transaction Identifier)和DB事務(wù)是一一對(duì)應(yīng)的關(guān)系,所以Relay Log中的數(shù)據(jù)本身已經(jīng)包含了所需要的復(fù)制元數(shù)據(jù),所以我們可以不寫Master info文件,消除了冗余的文件I/O;
于DB都是以事務(wù)為更新粒度的,因?yàn)樵赗elay Log文件I/O上,我們通過合并離散小I/O為事務(wù)粒度的大I/O等手段,使磁盤I/O得以大幅提升。
如上圖所示,經(jīng)過優(yōu)化:左圖35.79%的鎖競(jìng)爭(zhēng)(futex)已經(jīng)被完全消除;同壓測(cè)壓力下,56.15%的文件I/O開銷被優(yōu)化到19.16%,Slave I/O線程被優(yōu)化為預(yù)期的I/O密集型線程。
如上圖所示,在原生MySQL中多個(gè)事務(wù)提交線程TrxN和多個(gè)Dump線程之間會(huì)同時(shí)競(jìng)爭(zhēng)Binlog文件資源的保護(hù)鎖,多個(gè)事務(wù)提交線程對(duì)Binlog執(zhí)行寫入,多個(gè)Dump線程從Binlog文件讀取數(shù)據(jù)并發(fā)送給Slave。所有的線程之間是串行執(zhí)行的!
經(jīng)過分析,我們的優(yōu)化策略是:
將讀寫分離開來,多個(gè)寫入的線程還是在鎖保護(hù)下串行執(zhí)行,每一個(gè)寫入線程寫入完成后更新當(dāng)前Binlog的長度信息,多個(gè)Dump線程以Binlog文件的長度信息為讀取邊界,多個(gè)Dump線程之間并行執(zhí)行。以這種方式來讓復(fù)制拓?fù)渲械腄ump線程發(fā)送得更快!
優(yōu)化后的示意圖如下:
經(jīng)過測(cè)試,優(yōu)化后的內(nèi)核,不僅提升了事務(wù)提交線程的性能,在Dump線程較多的情況下,對(duì)主從復(fù)制性能有較大提升。
如上圖所示,在原生MySQL中主備庫之間的數(shù)據(jù)發(fā)送和ACK回應(yīng)是簡單的串行執(zhí)行,在上一個(gè)事件ACK回應(yīng)到達(dá)之前,不允許繼續(xù)發(fā)送下一個(gè)事件;這個(gè)行為在跨園區(qū)(RTT 2-3ms)的情況性能非常差,而且也不能很好地利用帶寬優(yōu)勢(shì)。
經(jīng)過分析,我們的優(yōu)化策略是:
將發(fā)送和ACK回應(yīng)的接收獨(dú)立到不同的線程中,由于發(fā)送和接收都是基于TCP流的傳輸,所以時(shí)序性是有保障的;這樣發(fā)送線程可以在未收ACK之前繼續(xù)發(fā)送,接受線程收到ACK后喚醒等待的線程執(zhí)行相應(yīng)的任務(wù)。
根據(jù)實(shí)際用例測(cè)試,優(yōu)化后的TPS提升為15%左右。
在騰訊云上,不時(shí)遇到用戶APP異?;蛘連UG從而占滿DB的最大連接限制,這是CDB OSS帳號(hào)無法登錄以進(jìn)行緊急的運(yùn)維操作。針對(duì)這個(gè)現(xiàn)狀,我們?cè)贛ySQL內(nèi)核單獨(dú)開辟了一個(gè)可配置的連接數(shù)配額,即便在上述場(chǎng)景下,運(yùn)維帳號(hào)仍然可以連接到DB進(jìn)行緊急的運(yùn)維操作。極大地降低了異常情況下DB無政府狀態(tài)的風(fēng)險(xiǎn)。該帳號(hào)僅有數(shù)據(jù)庫運(yùn)維管理權(quán)限,無法獲取用戶數(shù)據(jù),也保證了用戶數(shù)據(jù)的安全性。
針對(duì)一些應(yīng)用對(duì)數(shù)據(jù)的一致性要求非常高,CDB在MySQL原生半同步的基礎(chǔ)上進(jìn)行了深度優(yōu)化,確保一個(gè)事務(wù)在主庫上提交之前一定已經(jīng)復(fù)制到至少一個(gè)備庫上。確保主庫宕機(jī)時(shí)數(shù)據(jù)的一致性。
除了以上提到的MySQL內(nèi)核側(cè)的部分優(yōu)化,我們也在外圍OSS平臺(tái)進(jìn)行了多處優(yōu)化。例如使用異步MySQL ping協(xié)議實(shí)現(xiàn)大量實(shí)例的監(jiān)控、通過分布式技術(shù)來加固原有系統(tǒng)的HA/服務(wù)發(fā)現(xiàn)和自動(dòng)擴(kuò)容等功能、在數(shù)據(jù)安全/故障切換和快速恢復(fù)方面也進(jìn)行了多處優(yōu)化。
感謝各位的閱讀,以上就是“MySQL內(nèi)核的深度優(yōu)化方式”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對(duì)MySQL內(nèi)核的深度優(yōu)化方式這一問題有了更深刻的體會(huì),具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián),小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章,歡迎關(guān)注!
名稱欄目:MySQL內(nèi)核的深度優(yōu)化方式
URL網(wǎng)址:http://jinyejixie.com/article32/gdgpsc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供軟件開發(fā)、響應(yīng)式網(wǎng)站、品牌網(wǎng)站建設(shè)、云服務(wù)器、網(wǎng)站設(shè)計(jì)、品牌網(wǎng)站制作
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)