如何配置Redis在磁盘写满时停止接收写入_设置min-slaves-to-write防御崩溃-Redis-PHP中文网

min-slaves-to-write仅控制主从同步的写入条件，不检测磁盘空间；它通过检查在线且延迟≤min-slaves-max-lag的从库数量来拒绝写命令，与磁盘满无关。

如何配置redis在磁盘写满时停止接收写入_设置min-slaves-to-write防御崩溃

min-slaves-to-write 不能防止磁盘写满，也不能让 Redis 在磁盘满时自动拒绝写入。 它只管主从同步的从库数量和延迟，跟磁盘空间完全无关。把这两个问题混在一起配，不仅无效，还会掩盖真正风险点。

这个配置的作用对象是「从库连接状态」，不是「本地磁盘剩余空间」：

min-slaves-to-write 检查的是 connected_slaves 数量和每个从库的 slaveX_sync_delay（即复制偏移量延迟），不读取 df 或 stat 任何磁盘指标
即使 /var/lib/redis 分区只剩 1KB，只要从库在线且延迟 ≤ min-slaves-max-lag，Redis 照样接受写命令
磁盘写满后真正出问题的环节是：fork() 失败（RDB/AOF rewrite）、AOF write() 系统调用返回 ENOSPC、或 OOM Killer 杀进程——这些都发生在内核层，min-slaves-to-write 压根不介入

它不会优雅地“拒绝写入”，而是以不可控方式失败：

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

RDB 快照生成时 fork() 报 Cannot allocate memory：常见于 vm.overcommit_memory=0 + 大内存实例，此时 Redis 直接记录错误但继续运行，后续持久化全失效
AOF 重写期间老 AOF 文件持续增长，叠加新写入追加，write(2) 返回 ENOSPC → Redis 日志出现 Failed to write to AOF file: No space left on device，接着可能 crash 或进入只读模式（取决于版本）
系统级磁盘满导致 journald 或 syslog 写失败，触发 systemd 强制 kill redis.service（尤其在 RuntimeMaxUse 限制下）

必须跳出 Redis 配置层，直接操作系统和监控链路：

给 /var/lib/redis 所在分区启用 usrquota 或 grpquota，用 setquota -u redis 0 5242880 0 0 /var/lib/redis 设硬上限（单位 KB），避免单个用户占爆磁盘
在 redis.conf 中强制关闭 auto-aof-rewrite-percentage（设为 0），改用定时脚本+人工判断触发 bgrewriteaof，防止后台重写失控
部署两级监控：
– 基础层：用 inotifywait -m -e create,delete_self /var/lib/redis 捕获 temp-rewriteaof* 突增
– 应用层：每分钟执行 stat -c "%s" /var/lib/redis/appendonly.aof 2>/dev/null，对 AOF 文件大小做环比告警

值得，但目的完全不同：它是防脑裂和异步复制丢数据的，不是防磁盘满。正确姿势是：

配对使用：min-slaves-to-write 1 + min-slaves-max-lag 10，确保至少一个从库延迟 ≤10 秒才允许写入
必须配合 appendonly yes + appendfsync everysec，否则主库一挂，连本地恢复基础都没了
注意：如果用了 DynamicUser=yes 的 systemd 启动方式，min-slaves-to-write 会因无法识别从库 UID 而误判，此时得禁用 DynamicUser 或改用 group-based 配额

最易被忽略的一点：磁盘写满和主从同步是两个独立故障域，它们的告警路径、恢复手段、影响范围全都不一样。拿一个参数去“兼顾”两者，等于没防住任何一边。