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