MongoDB 升级3.4对均衡的影响

lyhabc

数据库扩容要趁早再趁早
背景

公司有部门春节期间做活动, 产品中使用了 MonogDB 做弹幕消息的收发和一些元信息的存储, 由于预计活动进行时会有流量上涨的情况, 需要对数据库进行扩容

在扩容前, 数据库有4个分片, 每个分片有几百 G 数据, 每个分片大概有5000个数据块, 总共有2w 个数据块

扩容为4分片扩8分片, 活动上线时间在两天后

当时使用的 MongoDB 版本为3.0

问题

在3.0的版本下, 数据块的迁移是全局串行的, 即同一时刻只能有一个数据块在迁移, 在线上开启了迁移, 进行了速度测试, 平均每个数据块的迁移时间为5分钟左右, 4分片扩8分片需要移动大约1w 个分片, 耗费的时间为10000 * 5 = 1个月

分析

MongoDB 在3.2以及之前的版本对数据的自动均衡做了全局串行处理, 在片数较多时不能发挥均衡的完整作用

为在指定时间内完成数据库扩容, 需要升级到增加了并行均衡的3.4版本

升级过程

按照官网要求, 3.0到3.4的升级不能直接进行, 需要先升级到3.2, 再升级到3.4

升级顺序为 mongod, config, mongos, 需要注意的有两点:
1. config 升级为复制集的过程较为繁琐, 参考config 升级复制集文档
2. 新版本 mongos 可能不能正确连接旧版本 mongod, 所以升级过程中, mongos 应该最后升级

效果

升级完成后, 首先看了一下单个数据块的迁移速度, 速度提升非常明显, 单个数据块的迁移时间从5分钟缩短到30s 左右, 有10倍的提升

再考虑到分片之间的并行迁移, 实际均衡时间由1个月降低到10000 * 0.5 / 4 = 18小时

在升级完成的一天内, 虽然遇到了一点别的问题, 数据库依旧完成了扩容

监控

mongodb 提供的 ops manager 监控, 比较方便可以搭建起来
在均衡过程中, 请求耗时增长可以接受
bd1fa2051919ba358243591f0

升级后的问题

有几个小问题

在迁移过程中, 出现了遇到 jumbo chunk 之后剩余的 chunk 不再继续迁移的问题, 具体表现是: set1中存在较多的 jumbo chunk( 较大的数据块), balancer 不断尝试迁移, 但是总是在连续两个 jumbo chunk 之间尝试, 在日志中不停打印类似的日志:
2017-01-20T11:38:21.030+0800 W SHARDING [conn4192015] possible low cardinality key detected in * - key is { uk: 247332434 }
2017-01-20T11:38:43.070+0800 W SHARDING [conn4192015] possible low cardinality key detected in * - key is { uk: 247332439 }
2017-01-20T11:39:07.806+0800 W SHARDING [conn4192015] possible low cardinality key detected in * - key is { uk: 247332434 }
线下复现未能成功, 线上一直存在问题

后使用脚本运行 movechunk 命令完成均衡

ops manager 的 ip 识别问题, 在进行监控时, ops manager 会将 ip 转化为域名进行记录处理, 但是存在的问题是, ip 与域名的映射并不总是完全准确的, 在映射错误的机器上使用 host 命令可以得到正确的结果, 导致的问题是, ops manager 对于映射错误的机器不能得到最新的数据
总体来说, 升级3.4版本对于均衡的收益是数量级的差异, 带来的效果十分明显, 对于均衡有需求的场景推荐升级