redis-check-rdb不能修复主从同步中的损坏rdb文件，因其仅能校验和报告问题，-f选项在redis 7+中已被移除，无法自动修复二进制结构；主从同步失败时应删除或重命名损坏文件，再以无持久化状态启动从库并重新触发全量同步。
redis-check-rdb 能否修复主从同步中的损坏 RDB 文件
不能直接修复用于主从同步的损坏 RDB 文件。redis-check-rdb 的作用是校验和报告问题，redis-check-rdb -f 的 -f 选项在 Redis 7+ 中已被移除，官方不再支持“自动修复”二进制结构——它最多跳过损坏键（仅限部分版本的 debug 模式），但无法恢复文件头、校验和或跨段偏移错误。
主从同步过程中，从库接收到的 RDB 是主库 bgsave 生成后直接传输的原始字节流。一旦传输中断、磁盘写入不完整或主库崩溃在 rdbSave 中途，从库保存的 dump.rdb 很可能缺少 EOF 标记、CRC 校验失败，或嵌入非法 type 字节（如日志中常见的 Invalid object type: 255）。此时 redis-check-rdb 只会报错退出，不会生成可用文件。
从库启动失败时，dump.rdb 文件必须删还是可以保留
必须删除或重命名。Redis 启动时若检测到 dbfilename 指定的 RDB 文件存在且不可解析，会直接 abort 并打印类似 Failed to load RDB file: short read or unsupported version 的错误，不会尝试加载 AOF 或跳过。
- 不要只改权限或 chown，Redis 会尝试读取并失败
- 不要用
truncate -s 0 dump.rdb，空文件仍会触发解析逻辑并报 checksum error - 稳妥做法是
mv dump.rdb dump.rdb.corrupted-$(date +%s)，留痕且避免误覆盖
主从同步场景下，如何安全跳过损坏 RDB 并重建数据
核心原则：让从库以“无持久化状态”启动，再重新触发全量同步。这比手动修复更可靠，也符合 Redis 主从设计语义——从库本就不该信任本地 RDB，而应以主库为准。
操作顺序必须严格：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 停掉从库：
redis-cli -p 6380 shutdown（确认端口） - 移走 RDB：
mv /var/lib/redis/dump.rdb /var/lib/redis/dump.rdb.bad - 临时禁用 AOF（即使没开也要检查）：
sed -i 's/^appendonly yes$/appendonly no/' /etc/redis/redis.conf - 清空 AOF 文件（如果存在且非空）：
> /var/lib/redis/appendonly.aof - 启动从库：
redis-server /etc/redis/redis.conf - 立即配置主从：
redis-cli -p 6380 replicaof <master-ip> 6379</master-ip>
此时从库会发起 SYNC 请求，主库执行 bgsave 并发送全新 RDB 流，整个过程绕过本地损坏文件。
为什么不能靠 --fix 参数启动 KeyDB/Redis 来抢救
--fix 是 KeyDB（Redis 多线程分支）的非标准扩展参数，Redis 官方版根本不识别。即便在 KeyDB 中启用，它也只是在 rdbLoad 阶段对单个 key 做 try-catch 跳过，并不修复文件结构本身。主从同步失败往往卡在 RDB header 解析或 DB selector 阶段，这时 --fix 完全不生效。
更关键的是：从库的 RDB 损坏通常意味着主库当时已处于异常状态（如 OOM kill、磁盘满、SIGKILL 强杀），此时主库内存数据本身可能已不一致。盲目跳过损坏部分加载，反而会把脏数据固化到从库，后续 replicaof 切换或故障转移时引发更大范围的数据错乱。
真正容易被忽略的点是：RDB 损坏很少孤立发生。它常伴随主库 INFO persistence 中 rdb_bgsave_in_progress:1 卡住、rdb_last_save_time 异常久远，或系统日志里有 write(2) failed: No space left on device。排查时别只盯从库，先确认主库是否健康。
