MySQL中GTID追蹤的自適應(yīng)路由查詢是怎樣的，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

創(chuàng)新互聯(lián)建站長期為1000+客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為許昌企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計，許昌網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

基于GTID追蹤的自適應(yīng)路由查詢

ProxySQL是一個工作在第七層(應(yīng)用層)且支持MySQL 協(xié)議的的數(shù)據(jù)庫代理，ProxySQL本身自帶了高可用和高性能的功能，并且包含了豐富的功能集。在即將到來的2.0版本中的功能將會更加excited！

ProxySQL中最常用的功能當(dāng)屬查詢的分析統(tǒng)計和基于路由查詢做到的讀寫分離。

當(dāng)客戶端連接到ProxySQL執(zhí)行查詢時，ProxySQL 會先根據(jù)預(yù)先設(shè)定好的路由規(guī)則進(jìn)行路由檢查，并分發(fā)到這條語句應(yīng)該被執(zhí)行的實例上。最簡單的例子就是將所有的讀查詢?nèi)柯酚傻綇膸欤械膶懖樵內(nèi)柯酚傻街鲙?。?dāng)然，由于讀查詢有可能在從庫上讀到非最新的數(shù)據(jù)，這個案例在生產(chǎn)上并不是實用的。因此，我們建議將所有的請求都發(fā)到主庫上，同時由于ProxySQL 對SQL統(tǒng)計信息的支持，DBA可以針對性的創(chuàng)建更加精準(zhǔn)的路由規(guī)則，將特定的查詢路由到從庫。詳細(xì)信息和其他案例可以參考之前的文章

在ProxySQL支持高客制化的路由規(guī)則設(shè)定，甚至可以通過next_query_flagIN參數(shù)指定當(dāng)前查詢連接的下一個查詢?nèi)匀辉谕唤M(hostgroup)實例上執(zhí)行，比如可以通過這個特性，指定插入數(shù)據(jù)語句的后面的查詢語句仍然在同一個實例上被執(zhí)行。但只有在DBA對應(yīng)用邏輯非常清楚的情況下，才能知道哪些功能或者查詢是先寫后查的，因此這個特性實際應(yīng)用起來比較復(fù)雜。

 上下文一致性讀

雖然某些應(yīng)用對數(shù)據(jù)實時性要求極高，但其對上下文一致性讀還是兼容的，即客戶端可以讀到同一個ProxySQL連接中被自己修改后的數(shù)據(jù)。這個特性在MySQL默認(rèn)的異步復(fù)制結(jié)構(gòu)是無法保證的，異步復(fù)制情況下，在主上提交寫后，從庫上有可能因為傳輸時間占用或者執(zhí)行速度的差異導(dǎo)致客戶端并不能同時讀到剛剛修改的最新數(shù)據(jù)。

那么我們?nèi)绾伪ＷC只有當(dāng)寫事件被完全同步到從庫后，查詢才會由ProxySQL路由到從庫呢？

基于GTID

GTID helps in this.

在MySQL 5.7.5更新后，客戶端可以知道其最后寫入事務(wù)的GTID，而且可以在任何當(dāng)前GTID代表的事務(wù)已經(jīng)被執(zhí)行的從庫上進(jìn)行讀操作。Lefred 在博客中舉例描述了這個過程，如下：MySQL實例服務(wù)端開啟session_track_gtids參數(shù)（這是個覆蓋全局和線程級的參數(shù)，用于返回當(dāng)前事務(wù)成功執(zhí)行的標(biāo)記和GTID編號）后，客戶端就可以在從庫上使用SELECT WAIT_FOR_EXECUTED_GTID_SET('3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5')的函數(shù)來判斷剛剛在主庫執(zhí)行的寫事務(wù)是否在從庫上已經(jīng)被執(zhí)行。

雖然可以通過這種操作來保證上下文一致性讀，但由于以下原因，這個方法對生產(chǎn)環(huán)境來說還是比較麻煩和不實用的：

在從庫上執(zhí)行業(yè)務(wù)查詢時每次都要加上WAIT_FOR_EXECUTED_GTID_SET的話，會增加單個查詢的響應(yīng)時間

出于效率，若想從若干個從實例中找到已經(jīng)執(zhí)行完指定GTID的實例，可能需要在所有的從庫上都執(zhí)行一遍

很可能所有的從庫在可接受的延遲等待時間內(nèi)都沒有完成該GTID的同步

也就是說上述的操作在生產(chǎn)環(huán)境中并不實用

 可以追蹤GTID嗎?

由于ProxySQL飾演著MySQL客戶端的角色，當(dāng)session_track_gtids 開啟后，ProxySQL 也可以跟蹤所有前端發(fā)來的所有請求的GTID，而且可以準(zhǔn)確的獲知每個前端連接最后的GTID值。這樣就可以使用這些信息去路由讀請求到正確的從實例（指已經(jīng)執(zhí)行完某個線程指定的GTID事務(wù)的從實例）上。那么，ProxySQL 怎么追蹤指定的GTID是否在從庫上已經(jīng)被執(zhí)行呢？

大概分為兩種辦法：

主動問詢：ProxySQL 定期的查詢所有實例的GTID執(zhí)行情況

聆聽告知，每當(dāng)一個新的寫事件產(chǎn)生且GTID編號被生成后，ProxySQL 會立刻接到告知

需要注意的是，由于每次問詢之間總是有一定的間隔，導(dǎo)致主動問詢方式總是不可避免的存在著基于問詢間隔的延遲，問詢的越頻繁，獲取的信息就越準(zhǔn)確，但會增加MySQL實例的負(fù)載，且當(dāng)ProxySQL實例過多時會占用查詢帶寬和流量?？偠灾?，理論上來說，這種辦法效率又低，架構(gòu)可擴(kuò)展性又差。

那么聆聽告知的情況

 實時獲取已經(jīng)執(zhí)行過的GTID值

從技術(shù)上來說獲取當(dāng)前已經(jīng)執(zhí)行過的GTID 值很簡單，只要實時消費（分析）binlog即可。但是這種方法需要把ProxySQL實例所在的機(jī)器模擬成一個從庫，如若單個ProxySQL負(fù)載了很多個MySQL實例，那么勢必會對提升CPU的消耗。更進(jìn)一步，如果一個機(jī)柜或者交換機(jī)上部署了很多ProxySQL 實例，那么傳輸binlog也會對整個網(wǎng)絡(luò)的帶寬帶來考驗。舉個例子，現(xiàn)有4個集群，每個集群中的主庫每天產(chǎn)生40GB的binlog并且掛了5個從庫，附加30個ProxySQL實例，那么，每個ProxySQL實例需要把自己模擬成24個主從實例的從庫?？傆嬅刻煲?0TB的網(wǎng)絡(luò)帶寬。對自建機(jī)房的話或許可以直接縱向或者橫向加硬件解決，但對云主機(jī)來說，每天將會無法避免巨額的流量費用。

ProxySQL Binlog Reader

主動問詢GTID執(zhí)行情況在上個段落中被認(rèn)為是沒有擴(kuò)展性，且消耗較大的資源的方法。ProxySQL Binlog Reader工具應(yīng)運(yùn)而生：

ProxySQL Binlog Reader是一個輕型，運(yùn)行在MySQL實例機(jī)器上，且通過把自己模擬成一個從實例連接到MySQL實例的跟蹤所有GTID事件的進(jìn)程。

ProxySQL Binlog Reader 本身就是一個服務(wù)器，每當(dāng)前端連接進(jìn)入時，就會開始以一個高效節(jié)省帶寬的方式進(jìn)行Binlog的流傳輸。

說到這里，我想聰明的您應(yīng)該猜到了ProxySQL實例飾演著ProxySQL Binlog Reader服務(wù)的客戶端的角色。

 實時路由

ProxySQL Binlog Reader 讓ProxySQL 可以知道每個MySQL實例當(dāng)前GTID 的執(zhí)行情況。那么，當(dāng)客戶端執(zhí)行一條讀寫分離查詢時，ProxySQL就會馬上知道這個請求該被路由到哪臺從服務(wù)器上。退一步說，即使當(dāng)前所有的從實例都沒有完成該GTID的執(zhí)行，那么ProxySQL 也會明白這是個主寫，從讀的查詢。

 細(xì)致的設(shè)置項，支持多集群

ProxySQL是高客制化的，本文所介紹的功能同樣如此。最重要的就是可以設(shè)置讀請求是否支持上下文一致性（以ProxySQL中的組為對象）。不能設(shè)置完上下文一致性就完事大吉，例如，針對一個讀請求，需要指定B組對A組滿足上下文一致性（這里的組指的是ProxySQL中的Hostgroup，A組應(yīng)該是寫組，B組則可寫，可讀，只要保證同一連接如果在A上寫，但讀被路由到B的時候，能夠讀到剛剛寫入的操作即可）。不僅支持主從之間上下文一致性讀，還支持切片集群A+切片集群B構(gòu)成的A-B高可用架構(gòu)中，上下文一致性讀查詢（被路由到A或B中），

 要求

基于GTID的上下文一致性讀需滿足如下條件：

Casual reads using GTID is only possible if:

ProxySQL 2.0 以后的版本

后端使用MySQL 5.7.5以上的版本，老版本不支持session_track_gtids

binlog格式為行格式

開啟GTID

后端僅限于Oracle或者Percona分支的MySQL，MariaDB不支持session_track_gtids

 結(jié)論

ProxySQL 可以路由查詢請求到指定的GTID已經(jīng)被執(zhí)行的從實例。本解決方案擴(kuò)展性極佳，網(wǎng)絡(luò)資源占用低，且已經(jīng)在實際環(huán)境中進(jìn)行驗證。

看完上述內(nèi)容，你們掌握MySQL中GTID追蹤的自適應(yīng)路由查詢是怎樣的的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

分享名稱：MySQL中GTID追蹤的自適應(yīng)路由查詢是怎樣的
文章地址：http://jinyejixie.com/article28/pgescp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、網(wǎng)站建設(shè)、商城網(wǎng)站、網(wǎng)站導(dǎo)航、網(wǎng)站營銷、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)