#作者：任少近

1.4 分片升级

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

1. 确认从节点： shard1,shard2,shard3
2. 升级从节点，一次必须一个。
3. 升级前两个库的情况，记录一下，后期对比情况。

1.5 升级shard1

1.5.1.1第一步：关闭并升级从分片
要关闭 mongod 进程，请使用 mongosh 连接到分片节点，并运行以下命令：
根据以上信息，确认分片从节点为server2.

[root@k8s-node6 bin]#mongosh mongodb://server2:27001

shard1 [direct: primary] test> use admin
switched to db admin
shard1 [direct: primary] admin> rs.status();

查询到server2有shard1为从节点，登录到server2上，关闭分片

shard1 [direct: secondary] admin> db.adminCommand( { shutdown: 1 } )
MongoNetworkError: connection 3 to 127.0.0.1:27001 closed
admin>

查到以下已经停止，进程也关闭。

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

启动server2上的shard1

[root@k8s-node6 conf]# mongod --config /usr/local/mongodb/shard1/conf/shard1.conf

查看状态：已恢复，stateStr: ‘SECONDARY’

查看进程，已正常。

查看版本,已确认到升级成功


1.5.1.2 第二步：关闭并升级ARBITER
要关闭 mongod 进程，请使用 mongosh 连接到分片节点，并运行以下命令：
根据以上信息，确认分片ARBITER为server3，进行升级。

要关闭 mongod 进程，请使用 mongosh 连接到集群节点，并运行以下命令

[root@k8s-node7 bin]#  mongosh mongodb://localhost:27001

shard1 [direct: arbiter] admin> db.adminCommand( { shutdown: 1 } )
MongoNetworkError: connection 2 to 127.0.0.1:27001 closed

启动server3上的shard1

mongod --config /usr/local/mongodb/shard1/conf/shard1.conf
查看状态：已恢复，stateStr: ‘ARBITER’

查看进程

查看版本

查看本地的版本

1.5.1.3第三步：升级主分片节点

1. 降级主分片节点，变为从分片节点
2. 关闭此从分片节点。
3. 并将mongod二进制文件替换为8.0二进制文件。
4. 请使用 mongosh 连接到主节点，并运行以下命令：
5. 启此从分片节点

1.5.1.3.1降级主分片节点。
登录到主分片节点上

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

也可以查看到rs.status()

1.5.1.3.2 升级主分片
关闭已降级主分片节点，
db.adminCommand( { shutdown: 1 } )

查看已降级的主分片节点状态，已经为异常状态，此进程也已停止。

替换二进制文件：
将mongod二进制文件替换为8.0二进制文件。

mongod
启动分片进程

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

查看本地版本

第一个分片shard1升级完成。

1.6 升级shard2,shard3

按相同方式升级shard2,shard3,不再赘述。

1.7 升级mongos

一个一个要升级mongos,并kill,重启,官方不支持重启。

将 7.0 二进制文件替换为 8.0 二进制文件。重启mongos

1.8重新启用负载均衡器

使用 mongosh 连接到集群中的 mongos，然后运行 sh.startBalancer() 重新启用负载均衡器：

sh.startBalancer()

查看状态

[direct: mongos] admin> sh.getBalancerState()

至此，升级完成。

1.9 推荐MongoDB Compass来验证数据

升级后，查询数据情况
通过rs.status(),查看库的情况：

两者比较没有任何变化。
查看此前插入的1万条数据。

本次可通过MongoDB Compass的可直观查看结果。

Server1上为3273个

Server2为3388个

Server3上为3339个

升级后，数据还是10000条数据，数据不会有丢失。本次升级成功。

2 注意事项：

1. 副本集和分片不应部署在同一主机上：将副本集（Replica Set）和分片（Shard）部署在同一台主机上是不利的，特别是在升级时。由于副本集和分片都使用相同的mongod程序，升级副本集需要替换mongod程序并重启，这会影响到正在运行的分片进程。尽管在本次测试中未观察到直接影响，但仍可能存在潜在的风险。虽然MongoDB官方文档中没有明确指出这一点，但从运维的角度来看，这种部署方式应尽量避免。

2. featureCompatibilityVersion的作用：尽管MongoDB已升级至版本8，但如果featureCompatibilityVersion仍设置为7.0，数据库的行为将遵循MongoDB 7.0的规范。如果将featureCompatibilityVersion从7.0更新为8.0，将会启用MongoDB 8中的一些新特性，并引入新的数据库行为。如果在生产环境中发现不兼容的问题，可以通过回滚到旧版本来解决这些问题；而在开发和测试环境中，这种方式更便于验证和测试。

3. 修改featureCompatibilityVersion的方式：可以通过以下命令在MongoDB中设置：
   db.runCommand({ setFeatureCompatibilityVersion: “8” })