Redis 5.0.7 BGSAVE断言失败被Signal 6终止问题求助

首先，你遇到的这个断言错误是Redis TimeSeries模块的Gorilla压缩算法在解析时序数据时触发的边界检查失败，直接导致后台持久化（BGSAVE）被信号6终止。结合你的使用场景，给你几个直接可行的排查和解决方向：

1. 优先排查模块版本兼容性 #

你当前使用的是Redis 5.0.7 + RedisTimeSeries模块，这个断言错误大概率是模块与Redis主版本的兼容性问题，或者模块本身的已知bug：

• 先确认你安装的RedisTimeSeries版本，找对应Redis 5.0.x的稳定发布版，升级/降级到经过验证的版本；
• 如果是源码编译的模块，建议拉取最新的稳定分支重新编译，这类断言错误大多已在后续版本中被修复。

2. 验证数据完整性 #

虽然重启后能正常加载DB，但可能存在部分损坏的时序数据条目，导致BGSAVE时解析失败：

• 先备份当前的RDB文件，避免操作丢失数据；
• 临时注释掉Redis配置里的loadmodule行，启动Redis时不加载TimeSeries模块，然后执行BGSAVE，如果能正常完成，说明问题确实出在模块和时序数据的交互上；
• 重新启用模块后，尝试逐步导入数据，排查是否是某条特定的时序数据触发了错误。

3. 临时调整持久化配置绕过问题 #

如果需要紧急恢复BGSAVE功能，可以尝试：

• 临时关闭自动BGSAVE，改用低峰期手动执行SAVE（注意SAVE会阻塞Redis，务必在业务低峰操作）；
• 检查Redis配置中的rdbcompression，如果开启了压缩，尝试暂时关闭，看是否能绕过这个压缩解析的断言错误。

关于重启日志的补充说明 #

重启后日志没有显示之前的BGSAVE成功记录是正常的——Redis启动时只会记录加载DB的结果，不会回溯历史的持久化日志。只要出现DB loaded from disk，就说明之前的BGSAVE确实生成了有效的RDB文件，这个无需担心。

内容的提问来源于stack exchange，提问作者Ashley Reid