干 DBA 這行SET GLOBAL read_only ON;這行命令大概是我手速最快的一條。主從切換要關(guān)寫、數(shù)據(jù)庫遷移要鎖源庫、半夜做備份怕業(yè)務(wù)把數(shù)據(jù)寫飄腦子剛把方案理清楚手指頭已經(jīng)把這行命令敲出去了。但要較真地講清楚這條命令很多人其實是含糊的read_only 到底攔誰、不攔誰為什么從庫開著只讀還能追上主庫的 binlog為什么有時候開了只讀應(yīng)用還被告知“寫入成功”這篇文章就按庖丁解牛的架勢把這條命令從權(quán)限模型、執(zhí)行邊界、運維場景到踩坑現(xiàn)場里外拆一遍。適合剛開始接觸主從復制的 DBA、被線上誤寫問題折騰過的運維以及想弄明白“只讀”和“不能寫”到底差在哪里的后端研發(fā)。1. 先拆解這條命令到底在干什么1.1 一行命令的三個部分SET GLOBAL read_only ON;可以拆成三段來看。SET GLOBAL表示這是一次全局系統(tǒng)變量設(shè)置。它面向整個 MySQL 實例所有連接——不管是這條命令執(zhí)行之前就建立的老連接還是之后新建的連接——都會受到這個變量狀態(tài)的影響。它不是一個 session 變量所以如果你手誤寫成SET read_only ON;MySQL 會直接回你一個錯誤Variable read_only is a GLOBAL variable and should be set with SET GLOBAL。read_only是 MySQL 自帶的系統(tǒng)變量直譯就是“只讀”。在 5.7、8.0 里它都是動態(tài)變量意味著不用重啟實例就能通過SET GLOBAL改狀態(tài)。ON是布爾值等價寫法是SET GLOBAL read_only 1;。OFF 或 0 表示關(guān)閉只讀。每次看到有人在這條命令后面注釋“開啟數(shù)據(jù)庫只讀”我都想補一句它開啟的是一種對寫入請求做“準入檢查”的狀態(tài)而不是把你的庫像 PDF 文件一樣整個鎖死。說到這里順便提醒一個高頻混淆點read_only和transaction_read_only是兩回事。后者也叫tx_read_only是會話級參數(shù)控制事務(wù)是否默認只讀比如START TRANSACTION READ ONLY這類行為它跟服務(wù)端能不能接受業(yè)務(wù)寫入沒有關(guān)系。查到報錯時先分清楚能少走很多彎路。1.2 它管住誰、放過誰read_only的攔截規(guī)則用一張表能說清楚行為read_onlyON 時是否被攔截普通用戶對持久表的 INSERT/UPDATE/DELETE/REPLACE攔截報 ERROR 1290普通用戶的 CREATE/DROP/ALTER/TRUNCATE 等持久表 DDL攔截普通用戶對 mysql 系統(tǒng)庫的寫入GRANT、CREATE USER 等攔截具有 SUPER 權(quán)限的賬號寫入不攔復制 SQL 線程從庫回放主庫 binlog不攔創(chuàng)建臨時表、在臨時表里寫入不攔SELECT、SHOW、EXPLAIN 等只讀查詢操作不攔第一行最好理解打開只讀后普通業(yè)務(wù)賬號的寫語句直接會被 ERROR 1290 懟回來。攔截粒度是 statement 級一條 UPDATE 在執(zhí)行前就被拒掉整條語句不會生效也不會產(chǎn)生 binlog。第二行容易被忽略其實 DDL 比 DML 更需要攔住。CREATE TABLE、ALTER TABLE 這類操作會改寫數(shù)據(jù)字典本質(zhì)也是寫只讀狀態(tài)下同樣報 1290。我之前見過有人以為“只讀只擋 DML不擋 DDL”結(jié)果在只讀實例上執(zhí)行 ALTER TABLE 失敗查了半天才發(fā)現(xiàn)是自己對只讀邊界理解有誤。SUPER 不攔這個設(shè)計本意是給 DBA 留一扇應(yīng)急門。實例開了只讀但出現(xiàn)明顯的數(shù)據(jù)錯誤需要立刻修復時高權(quán)限賬號可以不進維護窗口直接處理。但這扇門也是 read_only 最大的風險點后面講踩坑的時候會重點展開。復制線程不攔是底線邏輯。主從架構(gòu)里從庫常年開著 read_only 是常態(tài)binlog 回放線程本身就在做 INSERT/UPDATE如果 read_only 把回放也攔了從庫永遠追不平主從架構(gòu)直接崩掉。所以 MySQL 在實現(xiàn)上讓復制 SQL 線程擁有豁免權(quán)它執(zhí)行的事件不受只讀限制。這也是為什么你會看到只讀從庫的數(shù)據(jù)一直在變——這是正?，F(xiàn)象不是 read_only 失效。1.3 影響范圍立即、全局、不可商量read_onlyON的影響是即時且全局的命令執(zhí)行成功的下一秒所有連接的下一條寫語句就會開始報錯不需要重連不需要等緩沖。影響面包括所有普通業(yè)務(wù)賬號、運維平臺使用的低權(quán)限賬號以及臨時連上來做數(shù)據(jù)訂正的普通會話。對查詢流量則完全無感SELECT 照常走連接數(shù)也不會有波動。這里要特別提醒一點運維上不能只看數(shù)據(jù)庫這邊。應(yīng)用對寫入失敗的處理方式千奇百怪有的把 ERROR 1290 當成“連接壞了”觸發(fā)連接池重建結(jié)果瞬間把實例連接數(shù)打滿有的在重試邏輯里反復寫入幾分鐘內(nèi)把錯誤日志刷爆。所以切只讀之前一定要在演練環(huán)境里把應(yīng)用的行為摸清楚。這也是我為什么堅持把 read_only 當作“需要發(fā)布公告的變更”來管理而不是隨手敲完就走。2. 什么時候會用到 read_only從架構(gòu)保護到遷移維護2.1 主從架構(gòu)里的雙向保護主從架構(gòu)里read_only 承擔的是“雙向保護”。從庫這一側(cè)read_only 加上 super_read_only 是雙保險。從庫不應(yīng)該接收業(yè)務(wù)寫請求但總有例外某個同事把從庫地址當成主庫連了上去或者自動化腳本里配錯了節(jié)點。只靠賬號權(quán)限管理擋不住配置錯誤而 read_only 能在實例層直接把這種誤寫攔住。主庫這一側(cè)read_only 是切換流程中最關(guān)鍵的一道閘。標準的主從切換我一般是這么做的先在當前主庫執(zhí)行SET GLOBAL read_only ON;把業(yè)務(wù)寫請求擋在門外。確認目標新主庫已經(jīng)追平GTID 模式下對比gtid_executed非 GTID 模式看Seconds_Behind_Source是否為 0。在新主庫上停掉復制、清掉復制信息然后關(guān)掉read_only和super_read_only把應(yīng)用流量切過去。老主庫保持read_onlyON。這個狀態(tài)要一直維持到應(yīng)用流量徹底切走防止還有殘余請求落到老主庫上造成雙寫——這是防“雙主腦裂”最簡單也最有效的一層閘。有個細節(jié)值得說老主庫的 read_only 不會攔住復制通道。如果后續(xù)需要把老主庫重新搭成新主庫的從庫binlog 一樣能正常追上來。只讀閘門攔的是應(yīng)用寫入不是數(shù)據(jù)同步這個特性在切換過程中非常有用。2.2 維護窗口與數(shù)據(jù)遷移做線上大版本升級、批量數(shù)據(jù)訂正或者跨機房遷移數(shù)據(jù)時我最依賴的也是 read_only。遷移場景的具體節(jié)奏一般是源庫開 read_only → 記下當前位點或 GTID → 導出全量數(shù)據(jù)或開啟增量同步 → 在目標庫校驗行數(shù)和抽樣數(shù)據(jù) → 切流量 → 源庫關(guān) read_only 或直接下線。如果少了源庫只讀這一步校驗數(shù)據(jù)期間業(yè)務(wù)一寫源庫和目標庫的數(shù)據(jù)又會產(chǎn)生差異你根本沒法判斷到底是遷移漏了數(shù)據(jù)還是校驗期間產(chǎn)生了新增量。開了只讀之后你手里的每一個校驗結(jié)果都是可信的排查問題的口徑會清晰很多。維護窗口里的用法更純粹窗口時間有限希望 DBA 看到的、改到的就是最終數(shù)據(jù)。打開 read_only 之后哪怕業(yè)務(wù)側(cè)還有漏網(wǎng)的定時任務(wù)、漏改的配置在嘗試寫入也一律被 1290 擋住不會弄臟你的操作現(xiàn)場。2.3 備份與合規(guī)要求下的只讀保障備份場景里 read_only 不是必需的但要分情況。用mysqldump --single-transaction做邏輯備份時依賴 InnoDB 的 MVCC 就能拿到一致快照不需要關(guān)寫?？扇绻亲鑫募墏浞?、冷備或者在低版本、混合引擎的環(huán)境里一個“無寫入窗口”能省掉很多一致性上的麻煩。合規(guī)和審計場景用得更多。比如要給外部團隊開一個“數(shù)據(jù)查閱”入口或者給測試環(huán)境同步一份生產(chǎn)數(shù)據(jù)用于驗收你不可能逐賬號去收寫權(quán)限直接SET GLOBAL read_only ON;是最干凈的做法。開完之后不管是誰、從哪個入口進來都只能讀驗收結(jié)論才站得住腳。我遇到過的審計要求是“某個時間窗口內(nèi)庫內(nèi)數(shù)據(jù)零變更”這種要求除了 read_only沒有第二種更可靠的實現(xiàn)方式。3. 實操手冊怎么開、怎么關(guān)、怎么驗證3.1 三種設(shè)置方式與持久化差別先給出一份可以直接抄的設(shè)置對照設(shè)置方式生效時機重啟后是否保留典型場景SET GLOBAL read_only ON;立即不保留臨時維護窗口、切換流程SET PERSIST read_only ON;立即保留寫入 mysqld-auto.cnf需要長期固定只讀狀態(tài)MySQL 8.0 推薦my.cnf 中[mysqld] read_only ON重啟后保留從庫默認配置-- MySQL 8.0立即生效并持久化 SET PERSIST read_only ON; SET PERSIST super_read_only ON; -- 只寫配置、不立即生效下次重啟才應(yīng)用 SET PERSIST_ONLY read_only ON;SET PERSIST是 MySQL 8.0 開始支持的它會同時修改運行狀態(tài)并把配置寫入數(shù)據(jù)目錄下的 mysqld-auto.cnf。SET PERSIST_ONLY只寫配置不動運行狀態(tài)適合你預先把“下次重啟進入只讀”這個變更排進發(fā)版窗口的場景。5.7 沒有這些能力只能SET GLOBAL加改 my.cnf 兩條腿走路。權(quán)限方面也提醒一下5.7 設(shè)置這個變量需要 SUPERMySQL 8.0 改成了 SYSTEM_VARIABLES_ADMIN。權(quán)限不夠時你會看到ERROR 1227 (42000): Access denied這時候不是命令語法錯了是賬號權(quán)限不足。3.2 搭配 super_read_only我強烈建議一起開只開 read_only 是不夠的因為 SUPER 后門還開著。如果哪個同事拿 root 賬號“順手做個數(shù)據(jù)修復”寫入直接就進去了你精心準備的只讀窗口形同虛設(shè)。super_read_only是 MySQL 5.7.8 引入的變量專門用來堵 SUPER 后門開啟后擁有 SUPER 權(quán)限的賬號也不能執(zhí)行寫操作復制線程依然豁免。官方語義里super_read_only 只有在 read_only 也開啟時才真正生效所以生產(chǎn)環(huán)境的正確姿勢是兩條命令一起下-- 開啟先堵后門再關(guān)大門 SET GLOBAL super_read_only ON; SET GLOBAL read_only ON; -- 關(guān)閉兩條都放開 SET GLOBAL read_only OFF; SET GLOBAL super_read_only OFF;開啟順序我建議先 super_read_only 再 read_only因為 super_read_only 單獨開著沒有攔截效果先開它不會誤傷任何寫入等 read_only 一開SUPER 后門已經(jīng)被堵住空窗期最小。關(guān)閉時順序反而無所謂兩條都關(guān)掉就行。在從庫上我更推薦直接把兩個變量寫進 my.cnf讓從庫從啟動起就是只讀狀態(tài)而不是等故障發(fā)生了再靠腳本去補。3.3 一條命令驗證是否真的生效設(shè)置完別急著走驗證要跟上。先看變量狀態(tài)SHOW GLOBAL VARIABLES LIKE read_only; SHOW GLOBAL VARIABLES LIKE super_read_only; SELECT global.read_only, global.super_read_only;再用一個業(yè)務(wù)賬號實測寫入mysql -uapp_user -p -h127.0.0.1 -e INSERT INTO test.t1 VALUES (1); # 期望結(jié)果 # ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement注意報錯文案里說的是“--read-only option”即使你是用SET GLOBAL設(shè)的MySQL 也會用啟動參數(shù)的文案提示這個細節(jié)不影響判斷但別被它帶偏。最后確認一下復制狀態(tài)是否正常-- MySQL 8.0 語法 SHOW REPLICA STATUS\G -- 5.7 語法 SHOW SLAVE STATUS\G重點看Replica_IO_Running或Slave_IO_Running和Replica_SQL_Running或Slave_SQL_Running兩個字段是不是 Yes。如果從庫開著只讀、復制線程還正常說明配置是對的讀保護生效復制豁免也生效。4. 常見誤區(qū)和踩坑實錄4.1 誤以為 read_only 能攔下所有寫入這是最大的誤區(qū)。read_only 不攔 SUPER意味著所有能寫庫的“特權(quán)賬號”都在它的管轄之外。我經(jīng)歷過一次印象很深的演練主庫已經(jīng)開了只讀結(jié)果監(jiān)控系統(tǒng)里一個用于“自動清理過期數(shù)據(jù)”的賬號因為配置了 SUPER 權(quán)限在只讀狀態(tài)下照樣把一張線上表的歷史數(shù)據(jù)清了。那次之后我把所有能寫庫的自動化賬號重新梳理了一遍操作類賬號一律不給 SUPER真正需要 SUPER 的只保留在 DBA 手里從庫全部開啟 super_read_only。還有一個容易漏的點是定時任務(wù)如果數(shù)據(jù)庫里開著事件調(diào)度器event_scheduler事件的 DML 是以 definer 身份執(zhí)行的definer 如果是高權(quán)限賬號只讀狀態(tài)下一個“心跳表寫入”事件依然可能執(zhí)行成功。這不是 read_only 失效而是 definer 權(quán)限繞過了它。切只讀之前要么把事件調(diào)度器關(guān)掉要么把所有事件的 definer 收斂成無 SUPER 賬號。4.2 誤以為只讀庫里臨時表也不能用read_only 的校驗對 TEMPORARY 表是放行的臨時表只屬于當前會話不會影響持久數(shù)據(jù)所以服務(wù)器允許創(chuàng)建和修改臨時表。這本身是設(shè)計如此但應(yīng)用層的感知可能會出問題。我之前排查過一個案例應(yīng)用在寫主表之前先建臨時表做數(shù)據(jù)清洗然后 INSERT ... SELECT 把清洗結(jié)果寫進主表。只讀開啟后臨時表階段完全正常應(yīng)用日志里看不到任何報錯直到最后一步寫主表才爆 1290。業(yè)務(wù)方一度以為是數(shù)據(jù)庫“部分只讀”其實只是臨時表繞過了校驗而已。如果你要做的是“絕對無寫”的合規(guī)窗口連臨時表都不能被容忍那靠 read_only 是不夠的還需要從賬號層面收回CREATE TEMPORARY TABLES權(quán)限。記住一句話read_only 不等于沒有任何寫操作它攔截的是對持久化數(shù)據(jù)的寫。4.3 誤以為 read_only 可以暫停復制這是從庫維護里最常見的誤解。有人在從庫上執(zhí)行SET GLOBAL read_only ON;以為這樣就能讓從庫停止應(yīng)用主庫的 binlog結(jié)果數(shù)據(jù)還在一直變于是以為命令沒生效反復執(zhí)行。實際上 read_only 對復制線程完全沒有約束力。想暫停從庫追數(shù)據(jù)正確操作是STOP REPLICA; -- 這里執(zhí)行備份、維護操作 START REPLICA;注意 8.0 里STOP REPLICA是官方推薦語法5.7 里對應(yīng)的是STOP SLAVE需要 REPLICATION_SLAVE_ADMIN 或 SUPER 權(quán)限。這個誤解背后還有一個安全隱患有人開著 read_only 就去做物理備份以為“反正庫是只讀的文件是安全的”結(jié)果備份期間 SQL 線程一直在回放備份文件里的數(shù)據(jù)點是被撕裂的恢復出來主從不一致。記住 runbook 里的鐵律文件級備份之前必須STOP REPLICAread_only 替代不了這個動作。4.4 一次主從切換演練的真實復盤有一次做雙節(jié)點主從切換演練GTID 模式應(yīng)用賬號是低權(quán)限的 app_rw整套流程走下來基本順利但現(xiàn)場暴露了三個問題值得拿出來講。第一個問題是切換后仍有一小批連接在報 1290。查了半天發(fā)現(xiàn)是應(yīng)用連接池里還握著指向老主庫的舊連接而老主庫保持著read_onlyON。這些連接在流量切換之后第一次發(fā)寫請求直接命中只讀校驗。解決方案不是關(guān)掉老主庫的只讀而是讓應(yīng)用連接池盡快失效舊連接或者在代理層切換之后做一次應(yīng)用重啟。這個環(huán)節(jié)不處理好看到的現(xiàn)象會被誤判成“新主庫沒有正確放開寫入”。第二個問題在前面踩坑里提過老主庫上有個定時事件definer 是高權(quán)限賬號只讀狀態(tài)下它向心跳表寫入了一條記錄。當時讓現(xiàn)場的同學緊張了一下實際是 definer 權(quán)限繞過讀保護不是開關(guān)失效。從那以后我的切換清單里加了一項切只讀前統(tǒng)一檢查事件調(diào)度器狀態(tài)。第三個問題是切換結(jié)束后腳本沒有自動驗證新主庫的read_only確實為 OFF結(jié)果過了幾分鐘才發(fā)現(xiàn)新主庫的自動化配置里被寫入了一個只讀參數(shù)應(yīng)用開始報錯。現(xiàn)在我在切換腳本末尾強制加了兩步查global.read_only和global.super_read_only再用業(yè)務(wù)賬號做一次真實寫入。寧可慢幾秒不能帶著錯誤狀態(tài)上線。5. 快查速記與調(diào)試清單5.1 常見問題速查表把我在一線遇到的高頻問題整理成一張表遇到情況直接對著查現(xiàn)象排查思路處理建議應(yīng)用突然報 ERROR 1290確認實例 read_only 是否被打開檢查是否有自動化平臺誤操作屬于計劃內(nèi)窗口就通知應(yīng)用等待非計劃內(nèi)則評估后關(guān)閉只讀只讀已開啟但數(shù)據(jù)仍在變化區(qū)分是復制線程回放正常、SUPER 賬號寫入、事件任務(wù)寫入、還是臨時表操作從庫開 super_read_only收斂高權(quán)限賬號檢查事件 definer重啟后 read_only 丟失用的是 SET GLOBAL未持久化改用 SET PERSIST或在 my.cnf 中固定從庫開只讀后數(shù)據(jù)還在漲復制線程豁免只讀正?，F(xiàn)象需要停止追數(shù)時使用 STOP REPLICA執(zhí)行 SET GLOBAL 報 ERROR 1227當前賬號權(quán)限不足5.7 需要 SUPER8.0 需要 SYSTEM_VARIABLES_ADMIN關(guān)閉只讀后應(yīng)用仍寫不進去檢查 super_read_only 是否也關(guān)掉了檢查應(yīng)用是否還連著老節(jié)點兩條都關(guān)掉刷新應(yīng)用連接池5.2 我平時寫自動化腳本用的最小模板最后分享一個我自己在用的精簡模板可以當作切換、演練腳本的底子#!/bin/bash # 只讀模式控制腳本用法 ./readonly.sh on|off MYSQLmysql -uroot -p${MYSQL_PWD} -h127.0.0.1 case $1 in on) $MYSQL -e SET GLOBAL super_read_only ON; SET GLOBAL read_only ON; ;; off) $MYSQL -e SET GLOBAL read_only OFF; SET GLOBAL super_read_only OFF; ;; *) echo Usage: $0 on|off exit 1 ;; esac # 驗證并輸出當前狀態(tài) $MYSQL -e SELECT global.read_only AS read_only, global.super_read_only AS super_read_only;這個模板看起來簡單但有幾處是有意為之的開啟時先 super_read_only 再 read_only把特權(quán)賬號的空窗期壓到最小關(guān)閉時直接兩條都放開避免半吊子狀態(tài)最后強制輸出當前值讓人一眼確認結(jié)果。如果實例是 MySQL 8.0 并且希望重啟后保持狀態(tài)把SET GLOBAL換成SET PERSIST即可其余邏輯不變。最后說一個我個人的習慣每次切完只讀我都會先執(zhí)行一遍狀態(tài)查詢再順手用業(yè)務(wù)賬號跑一條插入測試。別嫌這幾秒鐘麻煩這條命令提供的確定性和安全感完全值得這個成本。數(shù)據(jù)庫的讀寫切換往往發(fā)生在最容易出錯的時間點越是看似簡單的命令越要用流程把它釘死。