MongoDB “升级项目”大型连续剧(1)|江阴雨辰互联

MongoDB “升级项目” 大型连续剧(1)

最近开始要迁移公司的大量的MONGODB到新版本，基于一个迁移并不是光会技术就可以了，我将开启一个MOGNODB 迁移连续剧，将整个的过程进行记录，让一个完整的迁移项目呈现给大家，还是那句话如果你光会技术，那只是你存活的必要条件，而不是充分条件。

第一集：非必要不升级与怎么干这个活

几十个MongoDB从我来的时候3.X已经升级到了4.X，当时我记得MOGNODB已经发布了6.0，当时没有升级到更高版本的主要原因，我回忆了一下。

1 当时大部分的MongoDB在3.2,3.6这个版本，升级的跨度不能太大，当时的应用程序在调试spring boot 的spring data mongodb 好像并不能良好的支持超过4.X以上的MongoDB

2 当时云厂商在云上支持的主流MongoDB为4.X ，5.0也支持，但用过云的都明白，暂不建议的意思。

所以基于稳定性和版本迁移的多方面原因，迁移是通过mongoshake 来进行的，整体迁移经历了半年，终于将所有的MONGODB 从3.X 变更到了 4.X。

时光如梭，岁月如何，我又老了几岁，MOGNODB已经发展到了8.0，基于某些原因我们提出过升级，但项目和业务并不CARE ，不牵扯利益的事情，有谁来想做。

最终非必要不升级是大多数甲方公司的使用数据库的日常场景，有PG用9.X的，有MYSQL用5.6的，还有REDIS 用2.8的，MONGODB 用3.2的，是的这就是现实。

但如果掌握的互相制衡和利益牵扯的，高阶DBA架构是不会放弃催动升级机会的能量，因为MONGODB4.2版本有一个问题compact无法在线回收删除数据的磁盘空间。

同时还有其他的问题如：在 MongoDB 4.2 及更低版本中，执行 compact 可能导致节点临时进入 RECOVERING 状态。若 hidden 节点被监控系统判定为不可用，可能触发自动重搭（replSet 重建节点）

compact 操作期间，hidden 节点可能因锁阻塞无法同步 oplog，导致与主节点的数据延迟增大，影响延迟节点的备份或分析功能。compact 通过重排数据文件回收空间，但在 4.2 版本中，若集合数据分布不均（如存在大量小碎片或 Jumbo Chunk），可能无法有效回收空间，甚至因无法满足压缩条件直接退出

而项目部门最近一直在优化成本，而他们一直以为删除了数据后，磁盘就会退回给系统，在MongoDB这里碰了一辈子灰后，且在云厂商给出了一个不顾公司死活的方案后，我给出了致命一击，把架构和某宇宙云的MOGNODB Service 大打一架，最终在我的努力下，重新开启的MONGODB的升级项目。

在升级中，很多人认为数据库升级就是数据库的问题，如果是初级的DBA就是那种干了1-2年的说出这话不怪他，没见过世面吗? 如果干了多年还说这话，你呀......！

一个数据库升级首先要带着架构和开发，因为数据库升级成功这事情是谁来判断，业务来判断成功，最终你的工作有没有成果是业务和开发说了算，你不带上他们你自己升级数据库产品，那是脑子让驴踢了。

迁移第一步：将困难说出来，将需要牵扯的人，牵扯进来，团结一切可以团结的力量，并且把能测试到的优点和缺点都测出来。

我是这样做的

1 将版本升级的功能特性列表，将可以升级的目标版本的优缺点进行了总结。当然如果你要把所有的优点都写出来是没有必要的，你列出一些开发关注的，对业务有帮助的优点，且同时你要发现版本中与业务和开发有抵触的严重的问题，放到你不推荐的版本中。

image

2 将升级可能带来的问题说清楚如：在升级中无法进行DDL操作，TTL索引会出现丢数据的可能，升级后语法变化特性，4.X升级后，5.0 6.0 7.0 等版本中的 writeConcern {w:1} 写法变为 {w:majority} 一些列的问题提出

3 学习目标新版本MONGODB 的特性,操作和语法的不同，以及一些原理的改变等等。

这些我后期再继续写。

下面主要的是要说说，如何进行测试，来证明升级后对原有系统的影响。

原有的系统是在阿里云上的4.2产品，需要迁移到MONGODB 6.0 根据业务的特性我们梳理出来需要对数据的插入和数据的更新两个部分进行操作。

这里我们可以选择成熟的测试工具，但部署和使用都比较麻烦，我这边采用通过NODE.JS来撰写相关的测试脚本，灌入数据，批量进行更新，因为测试只是找出不同而已，并没有特别严谨的测试要求，目的是找出性能的不同。

这里我把部分的测试脚本写到文章里面，在操作中将操作的时间打印出来，方便进行观察，同时匹配相关的数据库的监控图。（node.js简易测试程序）

代码语言：javascript代码运行次数：0运行复制

var dbName = "test_pre";
var collectionName = "perf_test";
var dataSize = 100000; // 插入数据量
var queryCount = 100000; // 更新次数

// 连接到数据库
var conn = new Mongo("");
var db = conn.getDB(dbName);
var collection = db.getCollection(collectionName);

// 打印开始时间
print(`[${new Date().toISOString()}] Script started.`);

// 清空集合
print('[INFO] Clearing collection...');
collection.deleteMany({});
print('[INFO] Collection cleared');

// 创建索引
print('[INFO] Creating indexes...');
collection.createIndex({ _id: 1 });
print('[INFO] Indexes created');

// 插入数据
print('[INFO] Starting inserts...');
var insertStart = new Date();
for (var i = 0; i < dataSize; i++) {
  collection.insertOne({ _id: i, randomValue: "test", status: "active", createdAt: new Date() });
}
var insertEnd = new Date();
print('[INFO] Inserts completed in ' + (insertEnd - insertStart) + 'ms');

// 更新数据
print('[INFO] Starting updates...');
var updateStart = new Date();
for (var i = 0; i < queryCount; i++) {
  var randomId = Math.floor(Math.random() * dataSize); // 随机选择一个 _id
  collection.updateOne({ _id: randomId }, { $set: { status: 'updated' } });
}
var updateEnd = new Date();
print('[INFO] Updates completed in ' + (updateEnd - updateStart) + 'ms');

// 打印结束时间
print(`[${new Date().toISOString()}] Script finished.`);

这里引入一个问题，在测试中如果测试不及你的预期怎么办，比如你想的是 MONGODB 6.0应该比你MOGNODB 4.2的数据库在各项操作中都会快，在测试中无法达到这个水平，你怎么去发现没有达到这个水平的原因是什么，这个也是一个问题，我们后面MONGODB升级连续剧继续说。

这里通过测试脚本，UPDATE的速度明显MOGNODB 6.0是有优势的，快乐有30多秒的速度，看来升级的确有优势。

当然后面还有很多工作要做，要知道后续，尽请关注！！

MOGNODB 6.0测试 100万数据UPDATE

MongoDB 4.2测试100万数据UDPATE

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-14，如有侵权请联系 cloudcommunity@tencent 删除数据库mongodb迁移测试数据

发布者：admin，转转请注明出处：http://www.yc00.com/web/1747669959a4678227.html

MongoDB “升级项目”大型连续剧(1)