尾部截断怎么处理
AOF 是追加写入的，机器断电时最后一条命令可能只写了一半就中止。aof-load-truncated 决定启动时如何面对这种尾部不完整的情况：默认值 yes 表示容错，加载到最后一条完整命令为止，同时记录一条警告日志；设为 no 则表现为启动失败，必须先人工处理文件。要强调的是，这个参数只处理「文件尾部不完整」，文件中段出现字节损坏仍会导致加载失败。
基本信息
| 参数 | aof-load-truncated，默认 yes |
|---|---|
| 默认行为 | 加载到最后一条完整命令并打警告日志 |
| 设为 no | 直接拒绝启动，要求先修复 |
| 适用范围 | 仅处理尾部截断，不处理中段损坏 |
| 日志关键字 | truncated |
典型使用场景
- 断电或异常重启后的启动排查与判断
- 制定启动容错策略：无人值守环境更倾向容忍截断
- 数据敏感场景：宁可拒绝启动也不接受少几条写入
- 事后收尾：截断发生后尽快重写 AOF 生成干净基线
- 监控规则：捕获截断关键字并触发告警
排查与收尾
排查与收尾
grep -i truncated /var/log/redis/redis-server.log # 确认是否发生截断
tail -n 5 /data/redis/appendonlydir/*.incr.aof # 查看尾部内容
redis-cli CONFIG GET aof-load-truncated # 复核当前策略
redis-check-aof /data/redis/appendonlydir/appendonly.aof.1.incr.aof # 校验文件
redis-cli BGREWRITEAOF # 生成干净基线，消除历史截断
redis-cli INFO persistence | grep -E 'aof_last_bgrewrite_status'两种取值的取舍
| 取值 | 启动表现 | 适用场景 |
|---|---|---|
| yes（默认） | 加载到最后一条完整命令并告警 | 一般生产环境，优先保证可用性 |
| no | 直接启动失败 | 数据敏感，要求人工确认后再启动 |
| 中段损坏 | 无论取值如何都会失败 | 需要从备份恢复或另行修复 |
| 截断后处理 | 重写生成干净基线 | 避免不完整文件长期保留 |
容忍截断意味着接受最后一条写命令可能丢失，这是可用性与完整性的取舍。数据敏感的业务要提前明确「能接受少多少条写入」，并配合副本冗余与对账手段兜底。
容忍截断不等于修复文件。文件本身仍是不完整的，长期保留会在之后每次启动时重复触发警告；确认数据无误后应尽快重写一次，把基线换成干净版本。