MongoDB “升级项目” 大型连续剧(2)-- 到底谁是“der“-EW帮帮网

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2790人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群260+ 9群)

上期写的是非必要不升级，想到这个事情，有一些事情的仔细琢磨琢磨，为什么数据库升级的事情在很多公司都是一个困扰，从一个技术人的观点，升级是一件好事，功能提升了，性能提升了，开发效率和一些数据库使用的痛点也被解决了，为什么就不愿意升级呢？

如果只是个人或这个单位的问题，为什么很多同学都反馈他们单位对于数据库升级这个事情并不积极呢？

这里我们不光需要批判的看，也要找到问题的真相，找到真相解决问题。

这里可以总结出几个可能得原因

1 业务重要程度高，升级数据库会影响业务的运行，产生不必要的风险，同时产生风险后，没有人愿意为之承担责任。

2 开发方并不认为当前的数据库产品有特别大的问题，并不愿意在此事上去消耗他们的精力。

3 运维方无动力升级产品，目前的产品运行良好，也无其他需求方提出异议，对数据库的功能和性能提出需求。

那么总结出来一句话，没有业务和开发的需求，数据库升级起来很难。

那么我们此次为什么升级MONGODB 4.2 4.4 到 6.0，我说一说需求。

一任何数据库产品都有保质期，这里我们可以参考MongoDB的MongoDB software LifeCycle Schedules 这里MonogDB 4.x 已经停止了生命周期。

https://www.mongodb.com/legal/support-policy/lifecycles

MongoDB life Cycle

当然这不足以提出升级，但在某些情况时可以提出的。

1 云上的服务商帮助，云上的服务商也是希望客户使用更新的数据库版本，替换掉老的产品，这样有助于他们降本增效。有人说这个怎么理解，云上的成本来自于硬件，一些数据库产品对新型的硬件并不支持，对与先进的硬件技术无法进行匹配，那么必然造成硬件资源的浪费，同时云厂商也要依赖于软件厂商的支持，那么end of life就是说人家数据库厂商不支持了，所以云厂商是希望去推更新版本的数据库产品给客户。

但这一切都不足以推动企业去升级数据库，除非版本太老，比如还有使用MongoDB 3.2的那么你在购买这个数据库产品，人家不支持了。

二、技术特性和吸引和必然性

我们以MongoDB举例，为什么我们此次要升级，主要的原因还是成本，我们在删除数据后，无法进行有效的在线的compact这都是MongoDB的数据库版本太低导致的。业务方和架构方都要求能进行删除数据后的在线数据collections 的收缩，所以必须要用新版本来完善这个事情。

但这样基本都是被动的，而与开发和架构业务多联系，了解他们的开发中的痛处才是我们升级数据库的好机遇。比如他们有时间数据处理的要求，而原有的传统关系型数据库不能满足需求，那么此时你可以提出MOGNODB 6.0有相关的时序性的功能帮助开发和架构完美的解决这类需求的问题，你需要给出文档和操作方面的介绍给他们，此时你不光是一个DBA，你还是一个数据库的推销者。

三、适可而止的升级与安全升级

这个问题是需要说一下的，主要在于不少从事DBA的同学对于升级的问题都是特别想一次到位，这个想法不要有，升级是没有到位的和数据库本身一直在功能变更时一样的，升级只要达到对应的目的即可，特别新或刚出的数据库版本，在我们这些老DBA的眼里都是坑，尤其核心的业务，我是不会去盲目升级到最新的版本，顶多是这个版本的上一个版本，或这个版本的最新的小版本，且至少1-2年以上。

同时你还要注意升级版本带来的问题，比如4.2 4.4的插入性能比更高版本好的一个原因是 writeConcern从 {w:1}改到{w:majority}这的确会损失性能，这点要进行测试和预估。

那么今天这个故事我就把4.X的一些大问题和 6.0的我们可以使用的技术优势写一写方便有需求的同学使用。

这里我总结一下阿里云的mongodb 4.2 4.4 版本的问题。

1 必须定期更换hidden节点的问题，在进行数据库备份的时候，备份上传期间磁盘会继续上涨，尤其hidden节点，因为不在用户的可见范围内，但hidden 节点本身会影响成本和磁盘空间的上涨，对于云厂商是一个难以解决的问题

2 分片的问题比较多，在4.X我们是不建议使用分片的，主要有以下几个问题

2.1 分片实例数据不均衡尤其在分片中 banlancer 按照分片间的chunks数量来判断是否均衡，存在 jumbo chunk empty chunks 等问题。

jumbo chunk 指的是某个数据块的大小超过了MongoDB的默认限制，如64MB 128MB

这样会直接导致查询和写入性能的降低分片均衡器也无法正常迁移这些超大块。

2.2 balancer 均衡速度慢，横向扩容性能差

在5.0以下的版本是无法快速均衡数据的，热点数据无法快速缓解，balancer的速度无法提升。

2.3 在进行 compact 的操作4.X的版本会有可能进入recovering的状态，这主要还是因为节点进入compact如果没有及时响应各个节点发来的探测信息，则判断此节点进入了无响应，则会产生节点变更状态进入recoverying的状态。

这里4.2.18版本实际上已经解决了上面的问题。但锁的问题解决不了。