MongoDB7分片副本集升级方案详解（上）

#作者：任少近

文章目录 前言：Mongodb版本升级升级步骤环境1.1环境准备1.2standalone升级1.3分片、副本集升级

前言：Mongodb版本升级

在开始升级之前，请参阅 MongoDB下个版本中的兼容性变更文档，以确保您的应用程序和部署与下个MongoDB兼容。在开始升级之前，请解决部署中的不兼容问题。 在升级 MongoDB 之前，请务必在临时环境中测试，然后再将升级部署到生产环境。 以下举例从7升级到8

升级步骤

1.首先确保是副本集状态 3.先关闭1个从节点 4.升级副本节点的可执行文件 5.更新配置文件 6.启动升级后的副本节点 7.确保集群工作正常 8.滚动升级其他副本节点 9.最后主节点降级 10.确保集群可用 11.关闭降级的老的主节点 12.升级老的主节点 13.重新加入集群

环境 1.1环境准备

系统系统 BC 21.10 三台服务器：192.168.123.247/248/249 升级包： mongodb-linux-x86_64-rhel8-8.0.3.tgz （截止2024年10月30日星期三最新版） mongosh-2.3.1-linux-x64.tgz

升级之前插入10000条数据，方便升级后验证。

[direct: mongos] admin>sh.enableSharding("foo"); [direct: mongos] admin>sh.shardCollection("foo.bar", {_id: 'hashed'}); [direct: mongos] admin> use foo for (var i = 0; i < 10000; i++) {db.bar.insertOne({i: i})};

查看多了一个bar库状态：

database: { _id: 'foo', primary: 'shard3', partitioned: false, version: { uuid: UUID('8beea767-f87c-4487-a0cf-8889022dc663'), timestamp: Timestamp({ t: 1730188226, i: 2 }), lastMod: 1 } }, collections: { 'foo.bar': { shardKey: { _id: 'hashed' }, unique: false, balancing: true, chunkMetadata: [ { shard: 'shard1', nChunks: 1 }, { shard: 'shard2', nChunks: 1 }, { shard: 'shard3', nChunks: 1 } ], chunks: [ { min: { _id: MinKey() }, max: { _id: Long('-3074457345618258602') }, 'on shard': 'shard3', 'last modified': Timestamp({ t: 1, i: 8 }) }, { min: { _id: Long('-3074457345618258602') }, max: { _id: Long('3074457345618258602') }, 'on shard': 'shard1', 'last modified': Timestamp({ t: 1, i: 6 }) }, { min: { _id: Long('3074457345618258602') }, max: { _id: MaxKey() }, 'on shard': 'shard2', 'last modified': Timestamp({ t: 1, i: 7 }) } ],

解释： foo.bar：表示数据库 foo 中的集合 bar。 shardKey：表示用于分片的键。这里的 { “_id”: “hashed” } 表示使用 _id 字段作为分片键，并且使用哈希分片策略（hashed sharding strategy）。 unique：表示是否为唯一索引。这里 false 表示 shardKey 不是唯一索引。 balancing：表示是否开启自动平衡。这里 true 表示自动平衡是开启的。 chunkMetadata：表示各个分片上的分块（chunk）数量。每个分块代表了一部分数据。这里有三个分片 shard1、shard2 和 shard3，每个分片上有一个分块。 chunks：具体展示了各个分块的范围和所在的分片。每个分块有一个 min 和 max 值来定义范围，并且指定了所在分片以及最后修改的时间戳。

总结 foo 数据库的主分片是 shard3，默认操作将在 shard3 上执行。 foo.bar 集合被分片，使用 _id 字段作为分片键，并且开启了自动平衡。 目前 foo.bar 集合的数据在 shard1、shard2 和 shard3 上分布，每个分片上有一个分块，具体分块的范围和所在分片的信息也已经给出。

查看bar库数据分布数 Shard1上分布3273 个 Shard2上分布3388个 Shard3上分布3339个 总数一万个

1.2standalone升级

升级就将数据备份好了，导出一份，直接升级，不再赘述。

1.3分片、副本集升级

如果部署的为分片、副本集，需要升级

分片集升级之前，先升级好副本集，确保在升级过程中保持数据的一致性和高可用性。 建议备份config数据库。

./mongodump --uri="mongodb://server1:27017,server2:27017,server3:27017" --db config -o /home/rsj/mongodb/config

1.3.1特征兼容性版本检查

所有副本集节点必须运行7.0版本。不然升级到8.0会失败。 featureCompatibilityVersion设立为"7.0" 。 要检查featureCompatibilityVersion ，执行 db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

该操作返回的结果应包含 “featureCompatibilityVersion” : { “version” : “7.0” }。

对于分片和配置服务器，请确保没有副本集成员处于 ROLLBACK 或 RECOVERING 状态。

通过db.adminCommand( { replSetGetStatus: 1 } )查看。

myconfigset [direct: secondary] test> use admin switched to db admin myconfigset [direct: secondary] admin> db.adminCommand( { replSetGetStatus: 1 } )

1.3.2下载 8.0 文件

请按照适用于 Linux 系统的 8.0 版本安装说明进行操作。这里为 mongodb-linux-x86_64-rhel8-8.0.3.tgz，然后执行实际的升级过程。

1.3.3升级副本集程序

使用“滚动”升级从 MongoDB 7.0 升级到 8.0，即在其他成员可用时单独升级各个成员，从而最大限度地减少停机时间。升级原则：

确认从节点升级副本集的从节点，一次必须一个。

1.3.4禁用负载均衡器。 在升级 MongoDB 时，需要禁用负载均衡器（Balancer），以确保数据在升级过程中不会被重新分配，减少潜在的数据不一致风险。 将 mongosh 连接到分片集群中的 mongos 实例，然后运行 sh.stopBalancer() 以禁用负载均衡器。登录任意一个节点 #mongosh mongodb://server1:27000

sh.stopBalancer() 验证是否已关闭 1.3.4.1第一步：关闭并升级从副本集之一 要关闭 mongod 进程，请使用 mongosh 连接到副本集节点，并运行以下命令： 根据以上信息，确认副本集从节点为server2.

[root@k8s-node6 bin]# mongosh mongodb://localhost:27017 myconfigset [direct: secondary] test> use admin switched to db admin myconfigset [direct: secondary] admin> db.adminCommand( { shutdown: 1 } ); MongoNetworkError: connection 2 to 127.0.0.1:27017 closed

已关闭。进程上也看到已不存在，此关闭是最优雅关闭，能确保所有的数据都被持久化到磁盘后才关闭

将 7.0 二进制文件替换为 8.0 二进制文件。bin_7.0.14下为老版本的mongod mongod启动进程

mongod --config /usr/local/mongodb/config/conf/mongod.conf

查看server2状态，等恢复了再进行下一个。查看stateStr状态，恢复到SECONDARY状态， 查看本地的版本。 再登录已经显示为8版本 1.3.4.2第二步：并闭并升级从副本集之二

相同的方式关闭副本集从节点之server3. 将 7.0 二进制文件替换为 8.0 二进制文件。 mongod启动 等待恢复到SECONDARY状态，不再赘述。 结下来再升级最后一个节点：主节点

1.3.4.3第三步：升级主节点

降级主节点。关闭server1。并将mongod二进制文件替换为8.0二进制文件。请使用 mongosh 连接到主节点，并运行以下命令：启server1

1.3.4.3.1 降级主节点。 将 mongosh 连接到主节点，并使用 rs.stepDown() 降级主节点，强制选举新的主节点：

myconfigset [direct: primary] test> use admin switched to db admin myconfigset [direct: primary] admin> rs.stepDown() { ok: 1, ...

如图：降级完成后，主节点已经成为从节点。

当 rs.status() 显示主节点已降级，并且server2成员已显示为 PRIMARY 状态 1.3.4.3.2 升级主节点server1。

关闭server1, myconfigset [direct: secondary] admin> db.adminCommand( { shutdown: 1 } ) MongoNetworkError: connection 3 to 127.0.0.1:27017 closed

查看server1，已经为down状态，此时进程已停止， 替换二进制文件： 将mongod二进制文件替换为8.0二进制文件。 mongod 启动进程

mongod --config /usr/local/mongodb/config/conf/mongod.conf 查看server1状态，已恢复，变成从，运行正常。