“no space left on device”不等于磁盘空间真满，很可能是inode耗尽、僵尸文件占用或挂载点嵌套导致；需依次执行df -h、df -i、lsof +l1、mount和du -shx排查。
哨兵配置写失败时，先确认是不是磁盘真满了
报错 Failed to rewrite config file: No space left on device 不代表一定没空间，得立刻验证。哨兵本身不存业务数据，但会持续写日志、临时配置片段、以及触发 CONFIG REWRITE（比如故障转移后更新主节点地址）。df -h 看挂载点（通常是 /var 或 /data）的 Use% 是否 ≥95%；更要跑 df -i —— 很多时候是 inode 耗尽，尤其在 ext4 上，大量小日志文件 + 频繁故障转移会快速占满 inodes，df -h 显示还有几 MB，但 df -i 显示 IUse% 100%。
清空日志必须用 truncate，不能 rm
哨兵默认日志路径是 /var/log/redis/sentinel.log（以启动参数或 logfile 配置为准）。直接 rm -f sentinel.log 是危险操作：Linux 下文件被进程打开后删除，磁盘空间不会释放，哨兵还可能因写入失败而卡住或崩溃。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 安全清空：用
truncate -s 0 /var/log/redis/sentinel.log，保留文件句柄，空间立即释放 - 删旧归档：若有轮转日志，执行
find /var/log/redis -name "sentinel.log.*" -mtime +7 -delete - 检查 AOF（仅当哨兵启用了 AOF）：
ls -lh /var/lib/redis/appendonly.aof*；若存在且巨大，临时关闭：redis-cli -p 26379 CONFIG SET appendonly no
CONFIG REWRITE 前必须先释放 inodes
inode 占满比磁盘空间满更隐蔽、更难恢复。哨兵每次故障转移都可能生成并快速删除临时配置片段，留下大量 deleted 状态的 inode（lsof | grep deleted 可查）。此时即使 truncate 日志，CONFIG REWRITE 仍会失败。
- 先找占用 inode 最多的目录：
find /var -xdev -type f | cut -d "/" -f 2,3 | sort | uniq -c | sort -n - 对哨兵相关目录（如
/var/log/redis、/var/lib/redis）清理无用小文件 - 若确认是哨兵进程本身持有大量已删文件句柄，用
kill -TERM $(pgrep redis-sentinel)安全重启（避免kill -9），让其释放 inodes 并重新加载配置
重写配置前务必备份并校验 sentinel.conf
CONFIG REWRITE 不是原子操作，它会覆盖原 sentinel.conf。如果配置里有手动添加的注释、include 引用或非标准语法，重写后可能丢失或格式错乱，导致哨兵下次无法启动。
- 执行前先备份：
cp /etc/redis/sentinel.conf /etc/redis/sentinel.conf.$(date +%s) - 重写后用
diff对比关键项（如sentinel monitor、sentinel auth-pass）是否被意外修改 - 用
redis-sentinel /etc/redis/sentinel.conf --test-conf校验语法有效性，再kill -USR2或重启生效
CONFIG REWRITE 对配置完整性的强依赖——这两点在告警堆叠时最容易被跳过。
