这类问题我又碰上了一次。Redis 6.2 开了 appendonly，数据盘用到九成时触发 AOF 重写，日志报 Background AOF rewrite finished unsuccessfully，随后写入全部返回 MISCONF。
第一反应是「磁盘满后 lastbgsave_status 变成 err，实例按配置拒绝写」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。AOF 重写要写一份全新的文件，峰值需要接近两倍数据量的空间；aof rewrite 期间旧 AOF 还在追加，两份文件同时增长；auto-aof-rewrite-percentage 设得太低，重写触发得很频繁。
上来先看当前是不是被拒绝写
redis-cli info persistence | grep -E 'aof_rewrite_in_progress|aof_last_bgrewrite_status'随后清出空间并把重写阈值调高
df -h /data && redis-cli config set auto-aof-rewrite-percentage 200再往下关掉 AOF 再打开，强制生成新文件
redis-cli config set appendonly no && redis-cli config set appendonly yes末了确认写入恢复且重写成功
redis-cli info persistence | grep aof_last_bgrewrite_status && redis-cli set probe 1隔了一天再看，现象没变，说明不是偶发。
改完先别撤，确认这几项。info persistence 里 aof_last_bgrewrite_status 是 ok，set 命令正常返回 OK，磁盘占用回落到七成以下。
提醒一点。AOF 重写要预留一倍空间，监控得按数据量的两倍设告警；用 no-appendfsync-on-rewrite yes 可以减轻重写期间的落盘压力。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。