如何在多服务器配置中开启只读模式_保护生产环境节点防止误操作的安全策略-phpMyAdmin-PHP中文网

MySQL从库需设read_only=ON并写入配置文件，8.0.22+建议加super_read_only=ON；Redis从节点执行CONFIG SET slave-read-only yes并写入redis.conf；PostgreSQL物理从库默认只读，需确认pg_is_in_recovery()返回t。

MySQL 主从架构下如何给从库加只读锁

生产环境的从库被误写入，几乎都是因为 read_only=0 且没设权限隔离。只靠应用层约定“不往从库写”根本不可靠，必须从数据库层强制限制。

核心操作就一条：登录从库 MySQL 实例，执行 SET GLOBAL read_only = ON;。但这只是临时生效，重启即失效，所以必须同步改配置文件。

my.cnf 或 mysqld.cnf 的 [mysqld] 段里加一行：read_only = ON
如果用的是 MySQL 8.0.22+，建议再加 super_read_only = ON（它会阻止 SUPER 权限用户绕过 read_only）
注意：开启 read_only 后，普通用户连 INSERT/UPDATE/DELETE 都会被拒绝，但 SELECT、SHOW、SET 仍可执行
常见坑：主库也误配了 read_only = ON → 导致主库无法写入，业务直接挂掉；务必确认只在从库节点上配

Redis 哨兵模式中让从节点拒绝写命令

Redis 本身没有全局“只读开关”，但从节点默认就不接受写命令——前提是没被手动 slaveof no one 或哨兵错误故障转移。

真正容易出事的是：哨兵集群脑裂或配置异常后，某个从节点被错误提升为主节点，又没及时降级，就会变成可写状态。

检查当前节点角色：运行 INFO replication，看 role:slave 且 master_host 不为空
强制锁定：在从节点上执行 CONFIG SET slave-read-only yes（注意不是 readonly，是 slave-read-only）
该设置重启失效，需写入 redis.conf：添加 slave-read-only yes
别信 CONFIG GET 返回值——某些旧版本 Redis 在哨兵管理下会忽略该配置，必须结合 INFO replication 和实际写入测试验证

PostgreSQL 流复制中防止从库被写入

PostgreSQL 的物理复制从库默认就是只读的，但很多人不知道：只要从库处于 recovery 状态，任何写操作都会报错 ERROR: cannot execute INSERT in a read-only transaction。这其实是安全的，但隐患藏在“退出恢复模式”这个动作里。

绝对禁止手动执行 pg_wal_rewind 或 pg_ctl promote，除非你明确要把它变为主库
检查是否仍在只读状态：连上去运行 SELECT pg_is_in_recovery(); —— 返回 t 才安全
如果返回 f，说明它已脱离复制、变成可写主库，需立刻查 pg_controldata 输出和日志里的 promote 记录
某些自动化脚本会静默调用 pg_ctl promote，建议在所有部署脚本里 grep 一遍，删掉或注释掉这类调用

Ansible 批量配置多服务器只读策略时的权限与顺序陷阱

用 Ansible 统一推 read_only 配置看似省事，但最容易翻车的地方不在语法，而在节点角色识别和执行顺序。

别用 group_names 粗暴区分主从——实际环境中可能有多个从组、跨机房从库、临时灾备节点，必须基于事实变量，比如 db_role: replica
修改配置后，不能直接 systemctl restart mysql：重启期间服务中断，且新配置可能因语法错误导致启动失败；应先 mysql --defaults-file=/etc/my.cnf -e "SELECT 1" 校验配置有效性
对 Redis/PostgreSQL 这类热加载不支持只读开关的服务，必须 reload 而非 restart，否则会中断复制连接；例如 Redis 用 redis-cli CONFIG REWRITE + kill -SIGUSR2（仅限支持版本）
最常被忽略的一点：Ansible 的 become_user 如果设成 mysql，会导致无法写入 /etc/my.cnf（权限不足）；应保持 become: true，用 root 改配置，再用对应服务用户重启进程