vault backup: 2026-05-25 23:07:45

hhs/Redis/06-主从与哨兵.md

@@ -230,7 +230,7 @@ flowchart LR
 Replica 默认是 **只读** 的（`replica-read-only yes`），这不是 Redis 故意限制你，而是有充分的技术原因：
 
 > [!WARNING] 为什么不应该在 Replica 上写数据？
-> 想象一下：你在 Replica 上写入了 `SET foo bar`，但 Master 上没有这个写入。下一次同步发生时，Master 会把自己的数据集"覆盖"到 Replica 上——你写的数据**悄无声息地消失了**。更糟糕的是，如果你在 Replica 上 `DEL` 一个不存在的 key，这个命令可能会被传播到 Master，导致 Master 上原本存在的数据被删掉。
+> 想象一下：你在 Replica 上写入了 `SET foo bar`，但 Master 上没有这个写入。下一次同步发生时，Master 会把自己的数据集"覆盖"到 Replica 上——你写的数据**悄无声息地消失了**。注意 Redis 复制是**单向的**（Master → Replica），你在 Replica 上的写入不会反向传播到 Master，但这本身就意味着 Replica 和 Master 之间的数据已经不一致了。
 >
 > **结论**：在 Replica 上写数据，本质上是在制造**数据不一致的定时炸弹**。
 
@@ -254,8 +254,9 @@ replica-lazy-flush no                 # FULLRESYNC 时清空旧数据的策略
 
 # --- 副本同步相关 ---
 repl-diskless-sync no                 # 无盘复制：Master 不写 RDB 文件，
-                                      # 直接通过 socket 发给 Replica（适合 SSD 环境）
-repl-diskless-sync-delay 5            # 开启无盘复制后，等几秒让多个 Replica 同时接收
+                                      # 直接通过 socket 发给 Replica（适合磁盘 I/O 慢的环境，如云盘/HDD）
+repl-diskless-sync-delay 5            # 开启无盘复制后，等几秒让多个 Replica 同时连接并接收 RDB 流，
+                                      # 减少 Master 重复生成 RDB 的次数（不是随机延迟，有明确优化意图）
 repl-timeout 60                       # 同步超时阈值（秒），超时则断开重连
 ```
 
@@ -416,6 +417,9 @@ flowchart TD
 | 2 | **`replica-priority` 最小** | 配置中人为指定的优先级 | priority=10 优先于 priority=100；priority=0 表示"永不选我" |
 | 3（最低） | **Run ID 字典序最小** | 纯粹的 tie-breaker | 两个 Replica 前两项完全相同，选 Run ID 字母序靠前的 |
 
+> [!WARNING] 如果所有 Replica 都不健康怎么办？
+> Sentinel **不会强行执行故障转移**。如果所有 Replica 都已断线、数据严重滞后或不可达，Sentinel 宁可让系统保持不可用状态，也不会选出一个数据严重落后的 Replica 当 Master——这体现了"宁缺毋滥"的设计哲学。此时运维需要介入，排查 Replica 为什么全部掉线。
+
 **Step 2：提升为新 Master**
 
 Sentinel 向选中的 Replica 发送 `SLAVEOF NO ONE`，使其断开与旧 Master 的复制关系，变成独立的 Master。