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

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

基于GTID追蹤的自適應路由查詢

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

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

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

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

 上下文一致性讀

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

那么我們如何保證只有當寫事件被完全同步到從庫后，查詢才會由ProxySQL路由到從庫呢？

基于GTID

GTID helps in this.

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

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

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

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

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

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

 可以追蹤GTID嗎?

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

大概分為兩種辦法：

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

聆聽告知，每當一個新的寫事件產生且GTID編號被生成后，ProxySQL 會立刻接到告知

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

那么聆聽告知的情況

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

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

ProxySQL Binlog Reader

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

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

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

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

 實時路由

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

 細致的設置項，支持多集群

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

 結論

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

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

分享名稱：MySQL中GTID追蹤的自適應路由查詢是怎樣的
文章地址：http://www.chinadenli.net/article28/pgescp.html

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

廣告

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