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