Redis版本选择和升级“很麻烦”,一旦决策不当可能会引起较大的稳定性问题。最近稳定性话题很热,我也来蹭个热度,聊一聊Redis版本升级的“最佳实践”。
虽然本文聊的是Redis版本升级,但是我觉得可能对其他产品升级也有借鉴意义。
一般认为,数据库产品求稳不求新,我想原因大概2点:
我会持续关注release note、阅读新版本代码变化、github社区相关issue,从功能、成本、性能、稳定性、兼容性5个方面进行评估:
特殊的功能:function、module、向量等
数据清理优化:Redis 6.0 过期键过期优化、内存碎片整理。
使用自定义压测工具(公司标准数据集)进行压测绘图。
一般经验是7-8个小版本后可以考虑使用,Redis整体还是比较稳定
(1) 兼容新的配置选项:平台应该具备版本配置模版功能,每个版本有自己的配置模版:
(2) 老配置:需要测试老配置在新版本是否还生效(除了测试,跟踪release note和读源码也是一种方式)
例如不配置save配置,在Redis 6.2之前是等同于空、但是Redis 6.2后会使用默认配置实现auto save,那就是灾难性的。
不配置save = save 3600 1 300 100 60 10000
详见:[Redis 6.2&7 save配置的一个坑]
(1) 新的选项:例如Redis 7.0中有个P50 P99耗时统计、memory相关指标越来越全,监控平台能持续兼容。
(2) 改名字:例如Redis 5.0中Redis 4.0关于最大客户端缓冲区的名字是不同的。
4.0
client_longest_output_list
client_biggest_input_buf
5.0
client_recent_max_input_buffer
client_recent_max_output_buffer
有关升级工具本文不详细展开,后续单独写一篇
(1) 兼容性
RDB格式从Redis 4.0(version 8)到Redis 7.2(version 11)一共经历了4个版本的变化。如果你的Redis运维体系和RDB有关,相关工具必须具备兼容性,例如我们在redis-migrate-tool上持续迭代,除了新加的各种功能以外,完全兼容了RDB的各个版本,为我们做集群升级做了非常必要的准备。
(2) 效率
平滑升级(业务无感知、效率高、数据无损)相关工具或者平台
(3) 可回滚
工具和平台具备回滚能力:一旦升级失败可立刻回滚。
经过收益评估、性能测试、功能测试、稳定性测试、平台建设、工具建设后,等到Redis的小版本基本稳定(经常观测release note和github issue),我们可以开始升级工作,一般我会分为四个阶段。
使用类似tcpcopy的工具将一部分线上流量引入到新版本,观察收益、稳定性、性能、兼容性等。
组内会有一些平台组件用到Redis:Eating your own dog food
业务测试或者开发用的集群:此时主要关注业务侧耗时变化、性能变化是否符合预期。
功能性:例如业务用新的命令、新的数据结构,新的module(例如json)
譬如机房整体搬迁
我经历过3次Redis升级:
最近稳定性话题比较热,我也有一点简单感悟分享下:
14
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论