Redis主从复制中从库如何只读_在从库设置slave-read-only为yes保护数据一致性

从现在开始，我们要努力学习啦！今天我给大家带来《Redis主从复制中从库如何只读_在从库设置slave-read-only为yes保护数据一致性》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！

Redis从库默认只读，slave-read-only yes是防意外写入的保险栓；设为no后从库可写但导致主从数据不一致，因写命令不回传主库且故障转移会扩散脏数据。

Redis 从库默认就是只读的，slave-read-only yes 不是“开启只读”的开关，而是防止意外写入的保险栓——关掉它，从库就真能被写，但数据立刻不一致。

为什么从库写入会导致数据不一致

主从复制是单向异步的：所有写命令只在主库执行，再通过 replication backlog 或 psync 同步给从库。如果人为在从库执行 SET、DEL 等写命令：

• 这些变更不会同步回主库，主库不知道自己“被改了”
• 主库宕机后若发生故障转移，该从库升为主库，脏数据就变成合法数据
• 其他从库重新同步时会拉取这个错误状态，扩散不一致

slave-read-only 的真实作用和常见误操作

这个配置不是“让从库只读”，而是“阻止客户端执行写命令”。它的行为受启动时机和配置方式影响：

• 必须在从库启动前通过 redis.conf 设置 slave-read-only yes（默认值），运行中用 CONFIG SET slave-read-only yes 也生效
• 设为 no 后，普通客户端（非 MONITOR 或 DEBUG）可正常写入，但 INFO replication 里仍显示 role:slave
• 即使设为 yes，本地连接（127.0.0.1）或管理员用户（启用 requirepass 且有 admin 权限）仍可能绕过限制，取决于 Redis 版本和 ACL 配置

验证从库是否真正只读的实操检查项

别只看配置文件，要动手测：

• 用非本地地址连接从库（如 redis-cli -h 192.168.1.10 -p 6379），执行 SET test 1 —— 应返回 (error) READONLY You can't write against a read only replica.
• 检查 CONFIG GET slave-read-only 和 INFO replication | grep role，确认值为 yes 且角色是 slave
• 如果用了 Redis 6+ ACL，确认连接用户没有 +@all 或显式 +set 权限；ACL 权限优先级高于 slave-read-only

生产环境必须同步做的三件事

光设 slave-read-only yes 不够：

• 在 redis.conf 中显式写死该配置，避免容器重启或配置中心下发时遗漏
• 监控脚本定期检查所有从库的 slave-read-only 值和 connected_slaves 数量，异常立即告警
• 禁止应用直连从库做写操作——这不是靠配置拦得住的，得从服务发现和客户端 SDK 层面隔离读写路由逻辑

最危险的情况不是配置没开，而是开发测试时手动 CONFIG SET slave-read-only no 调试完忘了恢复，又没进配置管理流程。这种临时改动比配置本身更难追踪。

到这里，我们也就讲完了《Redis主从复制中从库如何只读_在从库设置slave-read-only为yes保护数据一致性》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！