做MySQL運維的朋友遲早會碰到一個繞不開的話題數(shù)據(jù)庫代理Proxy。業(yè)務(wù)量一旦上來主庫寫壓力高、從庫讀流量分配不均、主從切換要改一堆應(yīng)用連接串這些問題會逼著你去找一個能統(tǒng)一收口的中間層。MaxScale就在這種情況下進(jìn)入我的視野——它是MariaDB官方出品的MySQL/MariaDB代理能幫忙承擔(dān)讀寫分離、負(fù)載均衡、自動故障轉(zhuǎn)移和查詢路由。這篇指南我按一條真實上線路徑來寫先講清楚為什么需要它、部署前要想什么再給一套可直接套用的配置接著拆解路由和監(jiān)控的底層邏輯最后分享上線后踩過的坑以及maxctrl日常巡檢方法。不管你是剛接觸MySQL的新人還是正在做代理選型的DBA應(yīng)該都能從里面找到自己需要的那部分。1. 先從選型說起為什么是MaxScale而不是另一套代理1.1 沒有代理層之前我經(jīng)歷過的三個痛點最早維護(hù)一套單主雙從的MySQL集群時我的日?？梢杂萌齻€詞概括改配置、等發(fā)布、背鍋。業(yè)務(wù)線直接在配置中心里寫下多個從庫地址從庫擴(kuò)容時要挨個通知應(yīng)用方修改連接串某個從庫宕機(jī)后監(jiān)控明明紅了但應(yīng)用里的連接池還在向這個死亡地址發(fā)起新連接直到超時重試才緩緩反應(yīng)過來。主從切換更是一場災(zāi)難手動把從庫提升為主庫后還需要在配置中心里改一大圈讀寫地址期間整個聯(lián)調(diào)環(huán)境都處于不可用狀態(tài)。換句話講應(yīng)用層直接面向MySQL裸連接是把架構(gòu)的脆弱性暴露給了所有上游。我當(dāng)時的訴求很明確有一個統(tǒng)一入口應(yīng)用只配一個地址讀寫路由由入口負(fù)責(zé)主從切換時入口能自動感知并處理。這個訴求指向的正是數(shù)據(jù)庫代理層。理論上也可以自己在應(yīng)用里封裝一套多數(shù)據(jù)源路由Java有現(xiàn)成的sharding-jdbc、讀寫分離插件Go也有各種方案。但問題是公司里不同團(tuán)隊語言不統(tǒng)一、維護(hù)成本高一旦有人把事務(wù)和讀路由的關(guān)系搞錯線上故障就來了。代理層的價值在于把路由邏輯從業(yè)務(wù)代碼里抽出來收口到基礎(chǔ)設(shè)施層讓應(yīng)用只關(guān)心連一個地址。1.2 MaxScale、ProxySQL、MySQL Router、MyCat的定位差異選型階段我把市面主流方案都過了一遍。MySQL Router是MySQL官方出品的輕量路由配置簡單但功能偏少不太適合做復(fù)雜路由和故障轉(zhuǎn)移ProxySQL功能確實很強(qiáng)查詢規(guī)則、緩存、流量控制都有但配置體系比較重規(guī)則寫多了之后排查起來累MyCat更偏向分庫分表一旦引入就相當(dāng)于把整個數(shù)據(jù)訪問層都交給它改造量大。相比之下MaxScale走的是“聚焦讀寫分離和高可用”的路線配置結(jié)構(gòu)清晰和MySQL/MariaDB的復(fù)制體系貼合得很緊內(nèi)置的monitor直接管理主從感知、failover、rejoin不需要額外寫腳本。我當(dāng)時用一個小型壓測環(huán)境簡單對比過下面這張表基本說明了差異方案讀寫分離自動故障轉(zhuǎn)移配置復(fù)雜度分庫分表能力我對它的評價MaxScale成熟內(nèi)置和復(fù)制狀態(tài)聯(lián)動較低一個conf文件即核心不支持專注路由層讀寫分離和高可用組合場景最優(yōu)ProxySQL成熟依賴外部腳本或ProxySQL Admin配置高規(guī)則和庫表多不支持適合對查詢規(guī)則有極強(qiáng)定制需求的人MySQL Router基礎(chǔ)依賴InnoDB Cluster元數(shù)據(jù)低不支持輕量場景夠用復(fù)雜拓?fù)鋭e指望MyCat有較弱高支持分庫分表場景才會考慮如果你和我一樣核心痛點就是“讀寫分離不徹底、主從切換太痛苦”MaxScale是投入產(chǎn)出比最高的一款。它不需要改造業(yè)務(wù)SQL不需要引入分片鍵部署形態(tài)也足夠簡單。1.3 什么場景不適合用MaxScale選型教育了我一件事沒有萬能組件先想清楚它解決不了什么再決定要不要用它。MaxScale解決的是路由和讀寫分發(fā)不解決數(shù)據(jù)容量問題。如果單庫數(shù)據(jù)量已經(jīng)到幾個T且還在暴漲需要的是拆庫拆表MaxScale這個層級幫不上忙它不是分布式數(shù)據(jù)庫中間件不會幫你做分片計算。另外它也不負(fù)責(zé)修復(fù)主從復(fù)制本身的故障如果binlog損壞、延遲持續(xù)追不上MaxScale能做的只是把那個從庫標(biāo)記為Down或限制它參與路由真正修復(fù)復(fù)制鏈路還是得靠DBA自己。還有一個容易被忽略的點MaxScale本身有網(wǎng)絡(luò)轉(zhuǎn)發(fā)成本如果業(yè)務(wù)對延遲極其敏感每個查詢都多一跳代理會產(chǎn)生毫秒級損耗這種場景下需要權(quán)衡是否值得。你會看到MaxScale擅長的是把復(fù)雜多變的主從拓?fù)浞庋b成一個穩(wěn)定入口讓應(yīng)用側(cè)變簡單。這正好是業(yè)務(wù)量上升期團(tuán)隊最需要的。2. 部署前必須做的三件事拓?fù)?、賬號與版本2.1 推薦的最小生產(chǎn)拓?fù)溟L什么樣很多人一上來就裝MaxScale結(jié)果發(fā)現(xiàn)文檔里講了一堆概念反而不知道從哪開始。我建議部署前先在紙上畫清楚拓?fù)?。這里給一個最小但完整的生產(chǎn)參考[應(yīng)用服務(wù)] - [VIP: 10.0.0.10] | [MaxScale A] [MaxScale B] - 代理層可做雙機(jī) \ / [MySQL Master] [MySQL Slave1] | [MySQL Slave2]如果團(tuán)隊規(guī)模不大可以先用一臺MaxScale跑起來等穩(wěn)定了再引入Keepalived或MaxScale自身的多機(jī)方案做VIP漂移。關(guān)鍵點是MaxScale不要和MySQL部署在同一個宿主機(jī)上否則宿主機(jī)宕機(jī)時代理和后端數(shù)據(jù)庫一起離開整個入口就徹底沒了。2.2 先確認(rèn)后端主從復(fù)制本身是健康的MaxScale的monitor模塊很強(qiáng)大但它只負(fù)責(zé)“觀察”復(fù)制狀態(tài)不負(fù)責(zé)“建立”復(fù)制關(guān)系。如果你后端的主從復(fù)制本身就有問題MaxScale配置得再完美也只是把問題曝光得更明顯。在部署MaxScale前我建議先完成這些基本功每臺MySQL的server_id全局唯一log_bin開啟gtid_modeONMySQL 8建議開啟MariaDB 10.11之后也推薦從庫的read_only打開復(fù)制賬號已經(jīng)建好并確認(rèn)SHOW REPLICA STATUS里沒有報錯。只有主從復(fù)制鏈路本身穩(wěn)定MaxScale基于復(fù)制狀態(tài)做failover才有意義否則它會以為某個節(jié)點是健康的結(jié)果數(shù)據(jù)在主從間根本對不上。2.3 MaxScale專用賬號的權(quán)限設(shè)計與創(chuàng)建SQLMaxScale和MySQL之間需要兩類賬號一類是監(jiān)控賬號monitor模塊用它去連接每臺后端服務(wù)器檢測主從狀態(tài)、計算延遲、判斷節(jié)點角色另一類是路由賬號service在處理客戶端連接時會用它去向后端發(fā)起真正的數(shù)據(jù)庫連接。實際配置里二者可以共用一個賬號但建議分開權(quán)限更好控制。下面這套SQL適用于MySQL 8.x和MariaDB直接抄即可CREATE USER maxscale_monitor% IDENTIFIED BY M0nitorPassw0rd; GRANT SELECT ON mysql.user TO maxscale_monitor%; GRANT SELECT ON mysql.db TO maxscale_monitor%; GRANT SELECT ON mysql.tables_priv TO maxscale_monitor%; GRANT SELECT ON mysql.roles_mapping TO maxscale_monitor%; GRANT SHOW DATABASES ON *.* TO maxscale_monitor%; GRANT REPLICATION CLIENT ON *.* TO maxscale_monitor%; GRANT REPLICATION SLAVE ON *.* TO maxscale_monitor%; CREATE USER maxscale_route% IDENTIFIED BY R0utePassw0rd; GRANT SELECT ON *.* TO maxscale_route%; GRANT INSERT ON *.* TO maxscale_route%; GRANT UPDATE ON *.* TO maxscale_route%; GRANT DELETE ON *.* TO maxscale_route%; GRANT SHOW DATABASES ON *.* TO maxscale_route%;不推薦給路由賬號配超級權(quán)限。REPLICATION CLIENT這個權(quán)限很關(guān)鍵MaxScale需要它來讀取復(fù)制狀態(tài)如果沒有這個權(quán)限從庫的復(fù)制健康度會讀不出來節(jié)點可能被誤判為Down。mysql.user和相關(guān)系統(tǒng)表的SELECT權(quán)限則用于檢查后端賬號是否存在、當(dāng)前賬號的權(quán)限元數(shù)據(jù)權(quán)限缺失時MaxScale日志里會不斷刷“permission denied”的告警。這里要額外提醒一點如果你后端是MySQL 8.0默認(rèn)認(rèn)證插件是caching_sha2_password舊版本的MaxScale對它的支持不穩(wěn)定。穩(wěn)妥做法是在MySQL 8上建maxscale專用賬號時顯式指定mysql_native_passwordCREATE USER maxscale_monitor% IDENTIFIED WITH mysql_native_password BY M0nitorPassw0rd;新版MaxScale已經(jīng)兼容caching_sha2_password但如果你用的是老版本還是建議用這個方式避免連接認(rèn)證報錯。2.4 版本選擇與安裝方式MaxScale的版本史比較有意思早期是獨立版本號6.x、7.x后來跟著MariaDB的節(jié)奏切到了23.x、24.x。無論哪個時期6.4都是一個相當(dāng)穩(wěn)定的版本線上有一批老集群還在用它新項目我建議直接用24.x配置語法變化不大官方文檔也更完整。安裝方式上主流操作系統(tǒng)都可以從MariaDB官方源直接安裝。RedHat/CentOS系curl -Ls https://rpm.mariadb.com/maxscale/24.2/rhel/9/x86_64/maxscale-24.2.1-1.rhel.9.x86_64.rpm -o maxscale.rpm yum install -y maxscale.rpmDebian/Ubuntu系curl -Ls https://deb.mariadb.com/maxscale/24.2/ubuntu/pool/main/m/maxscale/maxscale-24.2.1-1.ubuntu.22.04.jammy_amd64.deb -o maxscale.deb apt install -y ./maxscale.deb實際上版本號一直在更新上面URL里的具體包名會變化最保險的方式是訪問MaxScale官方下載站選擇對應(yīng)系統(tǒng)和架構(gòu)的rpm或deb包。安裝完成后二進(jìn)制路徑通常在/usr/bin/maxscale配置文件在/etc/maxscale.cnf日志在/var/log/maxscale/maxscale.log。如果使用Docker部署注意把/var/lib/maxscale目錄持久化不然容器重啟后監(jiān)控數(shù)據(jù)和管理賬號信息會丟失這個坑后面單獨展開。3. 從一份最小配置到真正跑通讀寫分離3.1 先理解MaxScale的四個核心對象剛開始看MaxScale文檔容易被listener、service、monitor、server這些詞繞暈。我用一個餐廳的類比幫助理解server后廚的灶臺對應(yīng)每臺MySQL實例。service配餐規(guī)則決定“哪些菜去哪個灶臺炒”比如讀走A灶臺、寫走B灶臺。listener餐廳門口的接客窗口對應(yīng)應(yīng)用連接的IP和端口。monitor巡查員每隔幾秒去看每個灶臺是否還在正常運轉(zhuǎn)、哪口鍋是主灶。一個MaxScale進(jìn)程可以配置多個service、多個listener、多個monitor但最小可用的配置只需要一套。3.2 最小可用配置文件用vim打開/etc/maxscale.cnf寫入下面這段配置[maxscale] threadsauto admin_host127.0.0.1 admin_port8989 admin_usermaxadmin admin_passwordAdmin123 [server1] typeserver address192.168.10.11 port3306 protocolMariaDBBackend [server2] typeserver address192.168.10.12 port3306 protocolMariaDBBackend [MySQL-Monitor] typemonitor modulemariadbmon serversserver1,server2 usermaxscale_monitor passwordM0nitorPassw0rd monitor_interval1000 failover1 auto_rejoin1 [Read-Write-Service] typeservice routerreadwritesplit serversserver1,server2 usermaxscale_route passwordR0utePassw0rd master_accept_readstrue [Read-Write-Listener] typelistener serviceRead-Write-Service protocolMariaDBClient address0.0.0.0 port4006說幾個關(guān)鍵字段modulemariadbmon是MaxScale 6.x以后的監(jiān)控模塊名舊文檔里mysqlmon已經(jīng)廢棄。monitor_interval1000表示每1秒巡檢一次。對普通業(yè)務(wù)夠用對高可用要求更高的場景可以調(diào)到500但會增加監(jiān)控賬號的連接壓力。failover1開啟自動主從切換。首次啟動時我建議先設(shè)成0手動驗證一切正常后再打開避免誤判導(dǎo)致自動切庫。master_accept_readstrue允許主庫參與讀路由。主庫性能寬裕時開著能分?jǐn)傋x壓力如果主庫已經(jīng)是寫瓶頸把它設(shè)成false所有讀盡量走從庫。3.3 啟動MaxScale并驗證讀寫分離安裝完成后注冊成系統(tǒng)服務(wù)systemctl start maxscale systemctl enable maxscale啟動后用maxctrl list servers看節(jié)點狀態(tài)maxctrl list servers正常情況下你會看到類似這樣的輸出server1的State是Master, Runningserver2的State是Slave, Running。如果顯示Down先回頭看密碼和權(quán)限是不是給錯了這是90%啟動失敗的原因。然后從應(yīng)用視角連一次MaxScale的4006端口mysql -h 192.168.10.10 -P 4006 -uapp_user -p進(jìn)去后執(zhí)行SELECT server_id;多開幾個會話執(zhí)行幾次你會發(fā)現(xiàn)server_id在多個節(jié)點間變化說明讀流量已經(jīng)被分發(fā)到不同后端。要驗證寫路由是否走主庫可以開一個事務(wù)執(zhí)行SELECT然后看連接始終綁定在同一個節(jié)點上。不要指望單條查詢就能看到完美的輪流分發(fā)MaxScale的后端連接池會影響復(fù)現(xiàn)多開幾個并發(fā)連接體驗更明顯。3.4 從“最小配置”到“生產(chǎn)配置”缺少的幾塊拼圖最小配置能跑通但離生產(chǎn)可用還差幾步。failover1雖然開了但原主庫恢復(fù)后是否自動重新加入集群靠的是auto_rejoin1。生產(chǎn)上還需要考慮客戶端連接上限、從庫延遲閾值、大查詢隔離等這些在后面章節(jié)展開?？傊劝焰溌放芡ㄔ僦鸩秸{(diào)優(yōu)別一上來就堆滿全部參數(shù)。4. 路由、連接與故障轉(zhuǎn)移的底層邏輯4.1 SELECT不等于一定走從庫這是我見過最多的誤解以為配置了讀寫分離所有SELECT就一定會去從庫。實際不是。readwritesplit路由器的判斷邏輯是“語句類型 上下文狀態(tài)”。一個客戶端如果開啟事務(wù)BEGIN或autocommit0事務(wù)里的所有語句都會被固定到同一節(jié)點避免跨節(jié)點讀到不一致數(shù)據(jù)。也就是說事務(wù)里第一個語句是SELECT那這個SELECT可能就落在主庫上。如果你的應(yīng)用框架比如某些ORM默認(rèn)開啟事務(wù)把大量查詢包在事務(wù)里結(jié)果就是所有讀流量全部打在主庫從庫閑置主庫壓滿。遇到這種情況我先建議去查業(yè)務(wù)代碼里是不是把無關(guān)的讀操作也塞進(jìn)了事務(wù)。還有幾類語句也會被強(qiáng)制發(fā)往主庫SELECT ... FOR UPDATE涉及存儲函數(shù)、臨時表、GET_LOCK()等有狀態(tài)操作的語句。另外會話級別變量一旦被SET修改后續(xù)語句為了保持一致性也會留在主庫。代理能識別語法但無法判斷你的存儲函數(shù)是否“純讀”所以它選擇了保守策略。4.2 從庫選擇策略LEAST_CURRENT_OPERATIONS還是LEAST_ROUTER_CONNECTIONS當(dāng)多個從庫都可用時MaxScale如何挑選目標(biāo)配置項slave_selection_criteria控制這個邏輯。默認(rèn)值是LEAST_ROUTER_CONNECTIONS意思是從后端連接池中選當(dāng)前活躍連接數(shù)最少的節(jié)點策略偏向“連接均衡”。另一選項是LEAST_CURRENT_OPERATIONS偏向“正在執(zhí)行的語句數(shù)最少”能更快避開瞬時大查詢帶來的卡頓。我在實踐中發(fā)現(xiàn)LEAST_CURRENT_OPERATIONS更能反映節(jié)點真實繁忙程度因為它統(tǒng)計的是正在執(zhí)行的SQL操作數(shù)而連接數(shù)多不代表每個連接都在跑大SQL。配置里加上這一行[Read-Write-Service] typeservice routerreadwritesplit serversserver1,server2 slave_selection_criteriaLEAST_CURRENT_OPERATIONS如果某臺從庫復(fù)制延遲明顯高于其他節(jié)點可以設(shè)置max_slave_replication_lag單位秒超過閾值的從庫會被自動移出路由候選池避免讀到滯后太久的舊數(shù)據(jù)。4.3 應(yīng)用連接池、MaxScale會話、后端連接池三者之間的關(guān)系這是連接問題排查中最容易繞暈的地方。連接鏈路上實際上有三層應(yīng)用層連接池、MaxScale會話、MaxScale與MySQL之間的后端連接。應(yīng)用層連接池管理的是“客戶端到MaxScale”的連接MaxScale會為每個客戶端會話維持一條會話上下文但當(dāng)多個客戶端會話都指向同一個后端節(jié)點時MaxScale可以選擇讓它們共享后端連接這就是它自帶的連接復(fù)用能力。換句話說應(yīng)用側(cè)開500個連接后端MySQL不一定真的建500個連接MaxScale會按需復(fù)用有效降低MySQL端的連接壓力。但這不代表應(yīng)用側(cè)可以無限開連接。MaxScale的每個客戶端連接仍然要消耗文件描述符和內(nèi)存如果業(yè)務(wù)側(cè)把maximum-pool-size設(shè)成幾千單機(jī)MaxScale一樣會被打穿。建議應(yīng)用連接池設(shè)計遵循兩個原則一是壓測后確定合理上限而不是隨手填一個很大的值二是連接空閑超時要和MaxScale側(cè)的不一致錯開避免互相踩踏導(dǎo)致連接提前被回收。4.4 主庫宕機(jī)時MaxScale到底做了什么主庫故障的完整流程值得每個DBA刻在腦子里因為業(yè)務(wù)感知到的就是“連接閃斷了一下”但背后的動作其實很多monitor在下一個巡檢周期默認(rèn)1秒發(fā)現(xiàn)主庫連接異?；驈?fù)制狀態(tài)中斷將該節(jié)點標(biāo)記為Down。當(dāng)failover1時mariadbmon依據(jù)master_priority配置或復(fù)制拓?fù)湫畔慕】祻膸熘羞x舉一個新主。MaxScale將新主標(biāo)記為Master后續(xù)新事務(wù)全部路由到新主。已經(jīng)被故障主庫承載的舊連接會中斷應(yīng)用側(cè)需要重試。如果auto_rejoin1原主庫恢復(fù)后會被配置成新主的從庫自動沿著binlog或GTID追數(shù)據(jù)追平后重新標(biāo)記為Slave, Running。這個過程中最影響體驗的是第4步。應(yīng)用側(cè)如果沒有重試機(jī)制一次切換就會造成成批報錯。所以在生產(chǎn)環(huán)境里我一直強(qiáng)調(diào)MaxScale做好故障轉(zhuǎn)移只是前提應(yīng)用層連接池必須配置短超時快速重試這樣用戶才能無感知。5. 業(yè)務(wù)接入階段最容易翻車的連接問題5.1 應(yīng)用賬號必須在后端每臺服務(wù)器上同時存在MaxScale本身不存儲業(yè)務(wù)數(shù)據(jù)它把客戶端連接“翻譯”到后端MySQL時用的是你這個業(yè)務(wù)賬號在后端執(zhí)行SQL。也就是說應(yīng)用連接MaxScale時用的app_user必須已經(jīng)在server1、server2等所有后端MySQL上都創(chuàng)建好了且權(quán)限一致。我曾經(jīng)在接入階段遇到一個詭異現(xiàn)象連MaxScale后查詢正常但某些頁面偶爾報1045 Access denied。最后排查發(fā)現(xiàn)新擴(kuò)容的一臺從庫上忘了建app_userMaxScale把讀請求路由到這臺從庫時后端拒絕了認(rèn)證。解決方案很簡單把賬號創(chuàng)建SQL在所有后端節(jié)點都執(zhí)行一遍或者用配置管理工具統(tǒng)一下發(fā)數(shù)據(jù)庫賬號避免只在其中一臺機(jī)器上建。5.2 從庫read_only不一致帶來的隱患MaxScale通過monitor讀取每個節(jié)點的角色決定誰是Master誰是Slave。假如某臺從庫忘了設(shè)置read_only1盡管它名義上是Slave但實際上仍然可以寫。一旦應(yīng)用被路由到這個從庫執(zhí)行寫入數(shù)據(jù)就會在主從之間出現(xiàn)分叉且這種分叉不會自動修復(fù)最終只能手動重建該從庫。所以從庫一定要統(tǒng)一加上SET GLOBAL read_only ON; SET GLOBAL super_read_only ON;其中super_read_only在MySQL 8里能防止具有SUPER權(quán)限的賬號寫入保護(hù)性更強(qiáng)。這個經(jīng)驗說出來不值錢但生產(chǎn)環(huán)境的從庫漏配read_only的真實案例多到數(shù)不清尤其是大批量初始化從庫時腳本少執(zhí)行了一次。5.3 連接斷開的恢復(fù)路徑應(yīng)用層重試設(shè)計不管MaxScale的故障轉(zhuǎn)移做得多么順滑主庫宕機(jī)的那一瞬間舊連接一定是失效的。Java的MySQL Connector/J有一個autoReconnecttrue參數(shù)但它只對“連接空閑后重建”有效如果正在執(zhí)行事務(wù)時連接斷開這個參數(shù)不會救你反而可能讓你誤以為應(yīng)用能自動恢復(fù)。更可靠的做法是在應(yīng)用的數(shù)據(jù)訪問層加一層快速重試捕獲連接異常后短暫sleep然后重新從連接池獲取連接、重發(fā)之前失敗的語句。重試次數(shù)不宜多2到3次即可重試間隔建議100毫秒左右因為MaxScale完成failover通常在1到3秒內(nèi)如果重試批次太密集反而會疊加成對MaxScale的連接風(fēng)暴。6. 上線后我們追過的三類MaxScale疑難雜癥6.1 一個從庫延遲“吃掉”整個讀流量有次業(yè)務(wù)反饋高峰期查詢變慢我查MaxScale卻看到兩個從庫都處于Running狀態(tài)但實際只有一臺從庫在承擔(dān)讀流量。原因是那臺健康的從庫發(fā)生了嚴(yán)重復(fù)制延遲MaxScale按照默認(rèn)策略雖然沒把它剔除可新連接都在蜂擁往另一臺從庫上擠最終把那個從庫也壓垮了。排查后我把max_slave_replication_lag5加進(jìn)了service配置延遲超過5秒的從庫自動從路由池摘除。這就好比配餐時只讓上菜快的后廚參與出餐慢的灶臺先暫停接單。加了這個參數(shù)后讀流量在多從庫間的分配明顯均衡了。[Read-Write-Service] typeservice routerreadwritesplit serversserver1,server2,server3 max_slave_replication_lag56.2 認(rèn)證插件不兼容導(dǎo)致MaxScale連不上MySQL 8新項目搭了一套MySQL 8.0.32把MaxScale和它接好之后日志里持續(xù)出現(xiàn)“Unable to authenticate”的報錯。一開始以為是密碼錯反復(fù)驗證無誤后才發(fā)現(xiàn)問題出在認(rèn)證插件上。MySQL 8默認(rèn)的caching_sha2_password要求連接雙方都支持對應(yīng)的認(rèn)證流程老版本MaxScale對這種認(rèn)證的支持并不完整。解決方式有兩個方向升級MaxScale到支持caching_sha2_password的新版本或者在不出問題的前提下給MaxScale專用賬號指定mysql_native_password?？紤]到老集群里的MaxScale版本不好動我當(dāng)時用的是第二種方式新建賬號時顯式指定認(rèn)證插件問題立刻消失。6.3 大查詢淹沒了某個從庫報表團(tuán)隊的幾個同事喜歡直接連從庫在線跑大查詢一遍GROUP BY跑上幾分鐘直接影響線上讀路由。MaxScale本身不會幫你區(qū)分“這是報表查詢還是業(yè)務(wù)查詢”它能做的就是把路由規(guī)則定清楚。我的做法是給報表類場景單獨開一條通道拿一臺或幾臺從庫單獨組成一個新的service監(jiān)聽不同的端口比如4007專供離線查詢使用4006端口留給線上業(yè)務(wù)。這樣大查詢再猛也只影響報表通道不會拖垮線上讀流量。順便說一句如果你在某個查詢前面加/* maxscale route to master */這樣的注釋MaxScale會識別并把它路由到主庫這是一條內(nèi)置的hint路由適合偶爾需要強(qiáng)制走主庫的場景。6.4 Docker部署MaxScale時要注意的目錄和數(shù)據(jù)持久化現(xiàn)在不少團(tuán)隊習(xí)慣用Docker起中間件MaxScale也提供了官方鏡像。直接docker run雖然能跑起來但有個問題容器銷毀后/var/lib/maxscale里的數(shù)據(jù)會丟包括之前配置產(chǎn)生的監(jiān)控緩存、管理口令、以及部分持久化狀態(tài)。結(jié)果就是重啟后認(rèn)證狀態(tài)異常甚至admin賬號失效。用Docker部署時一定把配置目錄、日志目錄、數(shù)據(jù)目錄都掛到宿主機(jī)物理路徑上docker run -d \ --name maxscale \ -p 4006:4006 \ -p 8989:8989 \ -v /etc/maxscale.cnf:/etc/maxscale.cnf \ -v /var/lib/maxscale:/var/lib/maxscale \ -v /var/log/maxscale:/var/log/maxscale \ mariadb/maxscale:24.2另外容器里通常不會自動啟動systemd所以要用docker run的方式托管而不是在容器里執(zhí)行systemctl start maxscale。這個操作層面的差異容易讓第一次用Docker的人卡住半天。7. 日常巡檢三板斧maxctrl、REST API與日志7.1 每天上班先看的三個maxctrl命令MaxScale上線后日常巡檢不需要天天登到MySQL里看復(fù)制狀態(tài)用maxctrl會更高效。我每天的習(xí)慣是先跑三個命令maxctrl list servers maxctrl show services maxctrl list sessionslist servers看每臺后端節(jié)點的State重點關(guān)注有沒有節(jié)點變成Down以及主從角色是否符合預(yù)期。show services看路由服務(wù)的整體連接數(shù)、路由統(tǒng)計如果連接數(shù)比平時高出一截說明可能有應(yīng)用側(cè)連接泄漏。list sessions列出當(dāng)前客戶端會話遇到問題時要看有沒有哪臺客戶端占著大量會話不釋放。這三個命令的輸出很短但信息密度極大基本覆蓋了“節(jié)點健康、路由狀態(tài)、會話狀態(tài)”三個關(guān)鍵維度。建議寫個小腳本封裝成一條命令每天早晨跑一遍。7.2 用REST API把MaxScale接進(jìn)監(jiān)控平臺MaxScale自帶REST API默認(rèn)監(jiān)聽在admin_port也就是8989端口。公司有統(tǒng)一監(jiān)控平臺的可以直接把MaxScale的指標(biāo)接進(jìn)去。簡單驗證一下API是否可用curl -u maxadmin:Admin123 http://127.0.0.1:8989/v1/servers/返回的JSON里包含每個server的state、connections、replication lag等字段。我一般會重點采集節(jié)點狀態(tài)和復(fù)制延遲兩個指標(biāo)一旦state不是期望的角色就告警。對接Prometheus類平臺的話還可以用現(xiàn)成的exporter不過直接用REST API拉也一樣省去額外組件。7.3 日志里報“replication is broken”時先別急著刪server有段時間MaxScale日志里頻繁出現(xiàn)“Replica is broken”的告警第一反應(yīng)是這臺從庫的復(fù)制鏈路壞了。但我登錄MySQL看SHOW REPLICA STATUS復(fù)制卻是正常的。后來才明白MaxScale的mariadbmon對復(fù)制斷開的判定條件是多個維度組合包括半同步狀態(tài)、GTID位置是否持續(xù)推進(jìn)、監(jiān)控賬號讀復(fù)制狀態(tài)的權(quán)限是否足夠某個維度異常就會誤報。遇到報錯不要急著用maxctrl destroy server把節(jié)點移除先按順序排查監(jiān)控賬號的權(quán)限是否完整、后端MySQL的read_only和復(fù)制狀態(tài)是否正常、GTID是否持續(xù)更新。如果這些都沒問題再把monitor_interval適當(dāng)調(diào)大觀察是否還繼續(xù)誤報。我調(diào)過一次后日志瞬間安靜了。7.4 在測試環(huán)境強(qiáng)制演練故障比看十遍文檔都管用最后說一個個人習(xí)慣我會每隔一段時間在測試環(huán)境強(qiáng)制kill掉主庫進(jìn)程觀察MaxScale是否在預(yù)期時間內(nèi)完成failover、從庫是否自動提升、原主庫恢復(fù)后是否能重新加入。這套演練做下來maxctrl的常用命令基本就爛熟于心了。真正到生產(chǎn)故障時肌肉記憶比臨時翻文檔可靠得多。MaxScale的價值只有在“真的出過事”之后才能體會而提前演練就是給自己吃定心丸的最好方式。