MySQL中GTID追蹤的自適應(yīng)路由查詢是怎樣的

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

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

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

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

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

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

 上下文一致性讀

雖然某些應(yīng)用對數(shù)據(jù)實(shí)時(shí)性要求極高，但其對上下文一致性讀還是兼容的，即客戶端可以讀到同一個(gè)ProxySQL連接中被自己修改后的數(shù)據(jù)。這個(gè)特性在MySQL默認(rèn)的異步復(fù)制結(jié)構(gòu)是無法保證的，異步復(fù)制情況下，在主上提交寫后，從庫上有可能因?yàn)閭鬏敃r(shí)間占用或者執(zhí)行速度的差異導(dǎo)致客戶端并不能同時(shí)讀到剛剛修改的最新數(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 在博客中舉例描述了這個(gè)過程，如下：MySQL實(shí)例服務(wù)端開啟session_track_gtids參數(shù)（這是個(gè)覆蓋全局和線程級的參數(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í)行。

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

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

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

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

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

 可以追蹤GTID嗎?

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

大概分為兩種辦法：

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

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

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

那么聆聽告知的情況

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

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

ProxySQL Binlog Reader

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

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

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

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

 實(shí)時(shí)路由

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

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

ProxySQL是高客制化的，本文所介紹的功能同樣如此。最重要的就是可以設(shè)置讀請求是否支持上下文一致性（以ProxySQL中的組為對象）。不能設(shè)置完上下文一致性就完事大吉，例如，針對一個(gè)讀請求，需要指定B組對A組滿足上下文一致性（這里的組指的是ProxySQL中的Hostgroup，A組應(yīng)該是寫組，B組則可寫，可讀，只要保證同一連接如果在A上寫，但讀被路由到B的時(shí)候，能夠讀到剛剛寫入的操作即可）。不僅支持主從之間上下文一致性讀，還支持切片集群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í)行的從實(shí)例。本解決方案擴(kuò)展性極佳，網(wǎng)絡(luò)資源占用低，且已經(jīng)在實(shí)際環(huán)境中進(jìn)行驗(yàn)證。

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