read-only 作用與誤區

許多 DBA 以為設置 read_only=1 就能完全禁止從庫寫入，實際上擁有 SUPER 權限的用戶不受限制。本文通過實測揭示真實行為邏輯。

實測環境

Master: 192.168.1.100
Slave:  192.168.1.101 (read_only=1)
測試用戶: imbyrd

實測過程與結論

場景一：用戶擁有 ALL PRIVILEGES（含 SUPER）

-- 主庫授權
GRANT ALL ON *.* TO 'imbyrd'@'%' IDENTIFIED BY 'admin';

-- 從庫測試
mysql -u imbyrd -p
INSERT INTO hitest.test VALUES (14, 'fo');  -- ✅ 成功！

結論：SUPER 權限繞過 read_only 限制。

場景二：用戶僅有 DML 權限（無 SUPER）

-- 主庫收回 ALL，授予精確權限
REVOKE ALL ON *.* FROM 'imbyrd'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'imbyrd'@'%' IDENTIFIED BY 'admin';

-- 從庫測試
INSERT INTO hitest.test VALUES (16, 'dddd');
-- ❌ ERROR 1290 (HY000): The MySQL server is running with the --read-only option

結論：無 SUPER 時，read_only 生效，寫入被阻擋。

場景三：用戶擁有 ALL 但被 REVOKE SUPER

GRANT ALL ON *.* TO 'imbyrd'@'%' IDENTIFIED BY 'admin';
REVOKE SUPER ON *.* FROM 'imbyrd'@'%';

-- 從庫測試
INSERT ... -- ❌ 依然報錯 1290

結論：只要當前會話無 SUPER 權限，read_only 即生效。

核心結論總結

生產環境最佳實踐

1. 從庫強制只讀：read_only=1 + super_read_only=1（MySQL 5.7.8+）
2. 最小權限原則：應用賬號絕不授予 SUPER，僅授業務所需 DML/DDL
3. 管理員隔離：DBA 專用賬號擁有 SUPER，但嚴禁在從庫執行業務寫入
4. 監控異常寫入：審計日志監控從庫的 INSERT/UPDATE/DELETE/DDL 操作

MySQL 8.0 增強：super_read_only

[mysqld]
read_only = 1
super_read_only = 1  # 連 SUPER 用戶也禁止寫入，除非進程擁有 SYSTEM_VARIABLES_ADMIN 權限

此參數徹底解決「SUPER 繞過」問題，推薦所有生產從庫啟用。