Redis从节点能同步FLUSHALL，但需满足未只读、未LOADING、无复制中断；否则因丢弃命令或积压缓冲区覆盖导致不同步。
Redis 从节点能同步 FLUSHALL，但前提是它没被配置为只读、没在加载 RDB、且主节点没在执行该命令时发生复制中断——否则你会看到“数据清空了，但从节点还留着旧数据”这种错觉。
为什么 FLUSHALL 看似没同步？常见现象与真实原因
运维执行 FLUSHALL 后，主节点数据清空，但从节点数据还在，或延迟很久才消失。这不是 bug，而是以下几种情况叠加导致：
- 从节点处于
LOADING状态（比如刚完成 RDB 加载、正在重放 AOF），此时会拒绝执行任何写命令，FLUSHALL被丢弃，日志里通常有Ignoring command because node is loading the dataset - 主节点在发送
FLUSHALL前发生了网络闪断，从节点触发了部分重同步（PSYNC），但FLUSHALL恰好落在复制积压缓冲区（repl-backlog-size）被覆盖的范围外，导致该命令彻底丢失 - 从节点配置了
slave-read-only yes（默认），但它不影响接收和执行复制流中的命令；真正卡住的是：如果从节点启用了appendonly yes且 AOF 重写正在进行，某些 Redis 版本（如6.2.6之前）会在 AOF rewrite 子进程退出前暂存复制命令，造成延迟
FLUSHALL 在复制流中到底怎么传输？
它不是特殊指令，而是以标准 RESP 协议格式，和其他写命令一样走复制缓冲区（per-slave buffer）和复制积压缓冲区（global backlog）。关键点在于：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
FLUSHALL是一个“写命令”，主节点执行后立即更新自己的master_repl_offset，并把整个命令（包括参数，如FLUSHALL ASYNC）写入 backlog 和对应从节点的复制缓冲区 - 如果从节点已连接且状态正常（
connected+up to date），它会在下一个事件循环中收到并执行该命令，效果等同于自己执行了一次 - 注意：
FLUSHALL不会触发新的bgsave，也不会生成带数据的dump.rdb；但若主节点开启了 AOF，该命令会被追加到appendonly.aof文件末尾，从节点重放 AOF 时也会执行它
如何验证 FLUSHALL 是否真的同步了？
别只看 key 数量，要查复制状态和命令流本身：
- 在从节点执行
INFO replication，确认master_repl_offset和slave_repl_offset差值为 0，且master_link_status:up - 在主节点执行
DEBUG REPLICA-CONFIG（Redis 7.0+）或查看redis-cli --rdb /dev/stdout | head -20输出，确认最近几条命令包含*2\r\n$7\r\nFLUSHALL\r\n - 开启慢日志（
slowlog-log-slower-than 0）并在主节点执行FLUSHALL后立刻查SLOWLOG GET 1，能看到完整命令及耗时；再在从节点查同一时刻的慢日志，对比是否出现相同条目
最容易被忽略的坑：AOF 重写 + FLUSHALL 组合
这是生产环境最隐蔽的同步断裂点。当主节点同时满足：
- 启用了 AOF（
appendonly yes） - 设置了
auto-aof-rewrite-percentage，且刚好触发了bgrewriteaof - 在 AOF rewrite 进程尚未退出时执行
FLUSHALL
那么该 FLUSHALL 会先写入旧 AOF 缓冲区，但不会立刻刷盘；而 rewrite 进程生成的新 AOF 文件不含这条命令。最终从节点可能从新 AOF 加载出“未清空”的状态，直到下一次全量同步或手动干预。解决方案只有两个：禁用自动 rewrite（设为 0），或确保 FLUSHALL 总在 rewrite 完成后执行（查 INFO persistence 中的 aof_rewrite_in_progress:0 再操作）。
