flushdb是清空当前数据库所有key的写命令，从节点因read-only yes默认禁用，执行时返回“readonly you can't write against a read only replica”错误。
只读从节点默认禁用写命令，FLUSHDB属于写操作
Redis 从节点（replica）在启动后会自动设置 read-only yes，这是硬性限制，不是配置可选开关。只要角色是 replica，所有会修改数据的命令都会被拒绝，FLUSHDB 就是其中之一。它清空当前数据库所有 key，本质是批量删除——哪怕当前库为空，该操作仍触发写逻辑，主线程会尝试更新键空间、触发过期淘汰、记录 AOF 等，所以必然被拦截。
报错信息明确指向只读模式限制
执行 FLUSHDB 时返回的错误通常是：(error) READONLY You can't write against a read only replica.。注意这不是 ERR unknown command（那是重命名导致的），而是标准的只读拒绝提示。你也可以用 INFO replication 确认 role:slave 或 role:replica，再用 CONFIG GET readonly 查看值为 yes，就能闭环验证。
强行关闭只读模式风险极高，不建议在生产环境尝试
虽然可通过 CONFIG SET slave-read-only no 临时关闭只读（Redis 5.0+ 改为 replica-read-only no），但后果严重：
- 从节点数据将脱离主节点状态，后续主从同步可能失败或产生冲突
- 如果此时主节点也发生故障，这个“脱管”的从节点无法安全晋升为主节点
- AOF 或 RDB 文件中会混入非主节点产生的写操作，破坏一致性保障
- 多数运维平台和监控系统会直接告警该配置变更
真正需要清空数据时，应该操作主节点，或先提升从节点为新主（REPLICAOF NO ONE），再执行 FLUSHDB。
误以为从节点能执行 FLUSHDB 的常见诱因
有几种情况容易让人产生错觉：
- 连接时没确认当前节点角色，比如通过代理（Twemproxy、Codis）或 DNS 轮询连到了主节点，误以为是“某个从节点”
- 使用了
redis-cli -c（集群模式）但实际连的是单机实例，角色判断混乱 - 从节点刚完成故障转移（failover），但客户端缓存了旧的
INFO结果，未及时刷新角色状态 - 某些低版本 Redis（如 2.8）在特定配置下允许部分写命令，但行为不可靠且已废弃
最稳妥的方式始终是：先执行 ROLE 或 INFO replication，确认 role 字段再决定是否发送写命令。
