mysql如何防止从库被误写导致数据污染_设置read_only与super_read

仅设 read_only 不够安全，因 super 权限用户可绕过；必须同时启用 super_read_only 并限制高危权限，才能实现真正只读。

mysql如何防止从库被误写导致数据污染_设置read_only与super_read_only

为什么只设 `read_only` 不够安全

很多运维习惯性给从库加 read_only=ON，以为这就万无一失。但实际中，拥有 SUPER 权限的用户（比如 root、DBA 账号）仍能绕过该限制执行写操作——read_only 对 SUPER 用户完全无效。这意味着只要一个高权限账号连上从库并执行 INSERT 或 DROP TABLE，数据就立刻污染，主从不一致风险陡增。

常见误操作场景包括：DBA 临时登从库查数据时顺手删了测试表；监控脚本用 root 连从库做健康检查并意外触发清理逻辑；备份恢复脚本未区分主从，直接在从库执行 TRUNCATE。

read_only 仅阻止普通用户写入，SUPER 用户可无视
MySQL 5.7.6+ 才支持 super_read_only，旧版本需升级或换方案
该变量是动态的，重启后不会自动生效，必须写进配置文件

必须同时启用 `super_read_only` 才算真正只读

开启 super_read_only 后，连 SUPER 权限用户也无法执行写语句（除少数元数据操作如 SET 变量），这才是防止误写的兜底手段。它和 read_only 是“与”关系：两个都 ON，整个实例才真正只读。

注意：启用 super_read_only 会自动将 read_only 设为 ON，但反过来不成立。所以生产环境必须显式设置两者。

启动时加配置：super_read_only=ON 和 read_only=ON 都要写进 my.cnf 的 [mysqld] 段
运行时动态开启（需 SUPER 权限）：SET GLOBAL read_only = ON; SET GLOBAL super_read_only = ON;
检查是否生效：SELECT @@read_only, @@super_read_only; 二者都应返回 1
若主库也误开 super_read_only，会导致主库无法写入，切主前务必确认

权限账号要配合限制，否则形同虚设

即使开了 super_read_only，如果应用或 DBA 使用的账号本身有 SUPER 权限，且该账号被允许连接从库，那它仍可能通过其他方式绕过（比如用 mysqladmin flush-logs 触发某些副作用）。更稳妥的做法是：从库只授权最小必要权限。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

禁止给从库账号授予 SUPER、REPLICATION CLIENT（除非真需要查复制状态）、SHUTDOWN 等高危权限
应用账号统一用 SELECT + EXECUTE（存过）即可，绝不要给 INSERT/UPDATE/DELETE
DBA 登录从库应使用专用只读账号，而非共用 root；可用 CREATE USER 'ro_admin'@'%' IDENTIFIED BY 'xxx'; GRANT SELECT ON *.* TO 'ro_admin'@'%';
若用 ProxySQL 或中间件，可在路由层强制拦截写请求，作为双重保险

验证是否真被锁死：用真实账号测一遍

配置改完别急着上线，拿一个带 SUPER 权限的账号（比如 root）连从库，手动试几个典型写操作。这是最容易被跳过的步骤，但恰恰最能暴露配置漏洞。

执行以下命令，预期全部报错：

INSERT INTO test.t1 VALUES (1);
UPDATE mysql.user SET password_expired='Y' WHERE user='root';
DROP TABLE IF EXISTS test.tmp;
CREATE TABLE test.test_lock (id INT);

错误信息应类似：ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement。如果某条没报这个错，说明 super_read_only 没生效，或账号权限没被正确识别。

特别注意：MySQL 8.0.12+ 对 super_read_only 的校验更严格，但某些云厂商 RDS 可能屏蔽或阉割该变量，部署前务必实测。