Redis启动时若appendonly yes且appendonly.aof存在（无论内容是否有效），则强制加载AOF并完全忽略dump.rdb；仅当AOF文件不存在或appendonly no时才加载RDB，该规则主从一视同仁。

appendonly yes 时，Redis 主从节点重启都只认 appendonly.aof，完全忽略 dump.rdb —— 无论主库还是从库，只要 AOF 开启且文件存在，RDB 就不会被加载。

---

redis-server 启动时的加载逻辑优先级

• Redis 启动时先读配置项 appendonly：

  • 如果是 yes，直接尝试加载 appendonly.aof
  • 加载失败（比如文件损坏、格式错误、权限不足），会报错退出，不会 fallback 到 RDB
  • 只有当 AOF 文件根本不存在（或 appendonly no），才会去加载 dump.rdb

• 这个规则对主库、从库一视同仁。从库在首次同步前也是普通 Redis 实例，同样走这套加载流程。

• 即使你手动把一个新鲜的 dump.rdb 放进数据目录，只要 appendonly yes 且 appendonly.aof 存在（哪怕内容为空或只有几行），Redis 就只加载 AOF。

---

主从场景下 AOF 文件的来源与风险点

• 从库开启 AOF 后，它的 appendonly.aof 是自己写入的，不是从主库复制来的

  • 主库的写操作通过复制协议发给从库，从库执行后才追加到自己的 AOF 文件
  • 所以从库的 AOF 是“本地执行日志”，和主库的 AOF 内容不一致（尤其在网络延迟、重连、部分命令被过滤时）

• 如果从库重启，它用自己那份 AOF 恢复，数据状态 = 上次断连前本地执行完的所有命令

  

  redis-tools

  按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

  下载
  • 这通常没问题，但要注意：如果从库曾执行过 CONFIG SET、DEBUG 类命令，或发生过本地写（如 slave-read-only no 且有人直连写入），这些也会进 AOF，重启后会保留

• 主库重启也一样：它只按自己的 AOF 恢复，不会参考从库状态

---

redis-check-aof --fix 什么情况下必须用

• 当 AOF 文件末尾损坏（比如进程被 kill -9、磁盘满、断电），Redis 启动时报类似错误： Invalid argument reading the append only file 或 Bad file format

• 此时不能靠删文件硬重启（会丢数据），得先修复：

  redis-check-aof --fix appendonly.aof

  - 它会扫描文件，找到最后一个完整命令位置，截断后面脏数据 - 修复后务必人工检查日志是否合理（比如最后几条是不是 SET/DEL，有没有混入二进制乱码）

• 注意：redis-check-aof 不处理 RDB，也不修复网络中断导致的主从不一致，它只救 AOF 文件本身

---

AOF 开启后，Redis 对恢复路径极其“固执”——它不权衡、不协商、不 fallback。真正容易被忽略的是：主从各自维护独立的 AOF，重启恢复行为互不影响，但数据一致性完全依赖复制链路的健壮性，而不是文件本身。