京公网安备11010502063487号用可断开的 TCP 转发模拟从库断线,实测 repl-backlog-size=16 KB 时的部分重同步边界:断开期间主库写入 28032 字节仍是部分重同步、32000 字节起退回全量,约为配置值的 2 倍(backlog 的 histlen 会超过配置值:写入 30103 字节时 histlen = 30103);另附默认值 1 MB。
验证 Redis Cluster 节点离开与重新加入:从库被 kill -9 4222 ms 后被标 fail 但集群仍 ok,重启 63 ms 内回归(日志显示 PSYNC 因 ID 不符被拒、走 RDB channel 全量同步,INFO 计数却是 full +0);清空的节点是新 ID,旧 ID 成幽灵,CLUSTER FORGET 在一个节点执行后 761 ms 内传播到所有节点;旧主库重启 100 ms 内自动成为从库。
在有 30 万个 key 和持续流量的 3 主集群上加一个空主库并 rebalance:搬 4096 个槽用时 3.0 s,搬迁期间吞吐 29660 → 28548 ops/s(几乎不变)、p99 64 µs、最大延迟 23.2 ms;客户端 4080 次 MOVED、0 次错误;搬完后 30 万个 key 校验 0 个错误。
手工执行一个槽的在线迁移(IMPORTING → MIGRATING → GETKEYSINSLOT/MIGRATE → SETSLOT NODE),客户端持续 INCR/GET:搬 key 期间 807 次 ASK、0 错误,计数器 2024 次全部保留;中途放弃(SETSLOT STABLE)会让已搬走的 400 个 key 在目标节点 DBSIZE 里却对 KEYS / SCAN 不可见,check 与 fix 都说 OK,需要重新 IMPORTING 才能找回。
实测 MIGRATE:搬走源端 key、TTL 保留、COPY/REPLACE/BUSYKEY/NOKEY 的语义;它在源上同步执行——100 MB 的字符串 MIGRATE 232 ms、源节点被阻塞 231 ms(目标也阻塞 153 ms);KEYS 批量比逐个快 21 倍;目标冻结导致超时(IOERR)后,解冻的目标上出现了同一个 key,而源上仍在——两边都有。
集群里一个 200 MB 的大 key:三个主库槽位数 5461/5462/5461、DBSIZE 都约 10 万,内存却是 222 MB 对 12.2 MB;redis-cli rebalance 认为「No rebalancing needed」;迁移含大 key 的槽让源节点 PING 停顿 423 ms;主库阻塞 5 秒(DEBUG SLEEP 模拟)超过 cluster-node-timeout 后被判 FAIL、从库 4498 ms 升主。
模拟少数派被隔离(3 主集群里只让主库 X 留下运行,其余节点暂停 12 秒):X 在 4025–4434 ms(cluster-node-timeout 3000 ms)之内仍接受写入(窗口内 543–594 条),之后 cluster_state 变 fail、拒绝所有读写(CLUSTERDOWN);其余节点恢复后约 2965–3055 ms 回到 ok。
同时杀掉一个分片的主库和从库:默认配置下 5.0 s 后 cluster_state = fail,连幸存分片也拒绝读写;有 AOF 时重启主库 3.2 s 恢复、0/30000 个 key 丢失;没有持久化时集群同样 2.1 s「恢复」,却有 9998 个 key(33.3%)读不到;require-full-coverage no 时幸存分片继续服务;--cluster fix 可以把槽分给存活节点,代价是数据永久丢失。
启动 3 个只配置了主库地址的 Sentinel:185 ms 通过 INFO 发现 2 个从库,2.2 s 内经主库的 __sentinel__:hello 频道互相发现;12 秒里主库上 sentinel 的探测是 ping 34 次、publish 16 次、info 4 次;拓扑被写回 sentinel.conf。
实测 Sentinel 主观下线:冻结主库后 sentinel 在 down-after-milliseconds 之后(3000 ms 时约 3957 ms)标 s_down;单个 sentinel 的 s_down 不会触发故障转移;down-after 设 1000/3000/6000 ms 时实测约 1887/3957/6973 ms;主库进程活着但阻塞 6 秒同样被判下线并被替换。
实测 Sentinel 客观下线:quorum 2、3 个 sentinel,kill -9 主库后各 sentinel 在 3075–3161 ms 标 s_down、3164–4185 ms 达成 o_down 并开始故障转移;quorum 3 而只剩 2 个 sentinel 可用时 12 秒都没有 o_down、不切换;quorum 1 时 s_down 即 o_down。
从 Sentinel 事件流看故障转移投票:quorum 2、3 个 sentinel 时两个 sentinel 同时 +try-failover(epoch 1),各投自己一票,第三个 sentinel 投给先到的 sentinel0,sentinel0 以 2/3 当选(+elected-leader);quorum 1 但只剩 1 个 sentinel 可用时,o_down 立刻成立却拿不到多数票,12.1 s 后 -failover-abort-not-elected,25 秒都没有新主库。