将 3.6 分片集群降级到 3.4
在本页面
在尝试任何降级之前，请熟悉本文档的内容。
Downgrade Path
升级到 3.6 后，如果需要降级，建议将其降级到 3.4 的最新修补程序版本。
Create Backup
*可选，但推荐.*创建数据库备份。
Considerations
在降级过程中，您无法更改集合元数据。例如，在降级期间，请 不要 执行以下任何操作：
-
创建数据库的任何操作
-
任何以任何方式修改群集元数据的其他操作。有关分片命令的完整列表，请参见Sharding Reference。但是请注意，并不是Sharding Reference页上的所有命令都修改集群元数据。
Prerequisites
在降级二进制文件之前，必须降级功能部件兼容性版本，并删除所有具有 3.4 或更早版本的 3.6 功能incompatible，如下所述。仅当将featureCompatibilityVersion设置为"3.6"时，才需要执行这些步骤。
1.降级功能兼容版本
db.adminCommand({setFeatureCompatibilityVersion: "3.4"})
setFeatureCompatibilityVersion命令执行对内部系统集合的写操作，并且是幂等的。如果由于某种原因该命令未成功完成，请在mongos实例上重试该命令。
为确保分片群集的所有成员都反映更新的featureCompatibilityVersion，请连接到每个分片副本集成员和每个配置服务器副本集成员，并检查featureCompatibilityVersion：
Tip
对于已启用访问控制的分片群集，要对分片副本集成员运行以下命令，您必须以分片本地用户身份连接到该成员。
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
所有成员应返回的结果包括：
"featureCompatibilityVersion" : { "version" : "3.4" }
如果任何成员返回的featureCompatibilityVersion包含"3.6"的version值或targetVersion字段，请在 continue 操作之前 await 该成员反映版本"3.4"。
有关返回的featureCompatibilityVersion值的更多信息，请参见View FeatureCompatibilityVersion。
2.删除向后不兼容的持久功能
用 3.4 删除所有incompatible的持久功能。例如，如果定义了使用 3.6 查询功能(例如$jsonSchema或$expr)的任何视图定义，文档验证器和部分索引过滤器，则必须将其删除。
Procedure
降级集群
Warning
在 continue 进行降级过程之前，请确保所有成员(包括分片群集中的延迟副本集成员)均反映出先决条件更改。也就是说，在降级之前，请检查每个节点的featureCompatibilityVersion并删除不兼容的功能。
下载最新的 3.4 二进制文件。
使用软件包 Management 器或手动下载，可获得 3.4 系列中的最新版本。如果使用程序包 Management 器，请为 3.4 二进制文件添加新的存储库，然后执行实际的降级过程。
升级到 3.6 后，如果需要降级，建议将其降级到 3.4 的最新修补程序版本。
禁用平衡器。
如禁用平衡器所述关闭平衡器。
降级 mongos 实例。
降级二进制文件并重新启动。
降级每个碎片，一次降级。
一次降级碎片。如果这些分片是副本集，则对于每个分片：
Note
如果您不执行干净关闭，则可能会导致错误，导致无法启动mongod进程。
强制终止mongod进程可能会导致db.collection.count()和db.stats()的结果不正确，以及延长下次重新启动mongod进程的启动时间。
无论您尝试通过kill或类似命令从命令行终止mongod进程，还是使用平台的初始化系统发出stop命令(如sudo systemctl stop mongod或sudo service mongod stop)，都适用。
-
将 3.6 二进制文件替换为 3.4 二进制文件。
-
使用
--shardsvr和--port命令行选项启动 3.4 二进制文件。包括适合您的部署的任何其他配置，例如--bind_ip。
mongod --shardsvr --port <port> --dbpath <path> \
--bind_ip localhost,<ip address>
或者，如果使用configuration file，则将文件更新为包括sharding.clusterRole: shardsvr，net.port以及适用于您的部署的任何其他配置，例如net.bindIp，然后开始：
sharding:
clusterRole: shardsvr
net:
port: <port>
bindIp: localhost,<ip address>
storage:
dbpath: <path>
- await 该成员恢复到
SECONDARY状态，然后再降级下一个辅助成员。要检查成员的状态，您可以在mongo shell 中发出rs.status()。
对每个次要成员重复上述步骤。
- 降级主副本集。
将mongoShell 连接到主要数据库，并使用rs.stepDown()降低主要数据库并强制选择新的主要数据库：
rs.stepDown()
-
当rs.status()显示主要数据库已降级，而另一个成员已成为
PRIMARY状态时，则将已降级的主要数据库降级： -
关闭逐步降低的主数据库，并将mongod二进制文件替换为 3.4 二进制文件。
- 使用
--shardsvr和--port命令行选项启动 3.4 二进制文件。包括适合您的部署的任何其他配置，例如--bind_ip。
- 使用
mongod --shardsvr --port <port> --dbpath <path> --bind_ip localhost,<ip address>
或者，如果使用configuration file，则将文件更新为包括sharding.clusterRole: shardsvr，net.port以及适用于您的部署的任何其他配置，例如net.bindIp，然后启动 3.4 二进制文件：
sharding:
clusterRole: shardsvr
net:
port: <port>
bindIp: localhost,<ip address>
storage:
dbpath: <path>
降级配置服务器。
如果配置服务器是副本集：
-
一次降级副本集的secondary个成员：
-
关闭辅助mongod实例，并将 3.6 二进制文件替换为 3.4 二进制文件。
- 使用
--configsvr和--port选项启动 3.4 二进制文件。包括适合您的部署的任何其他配置，例如--bind_ip。
- 使用
mongod --configsvr --port <port> --dbpath <path> --bind_ip localhost,<ip address>
如果使用configuration file，请更新文件以指定sharding.clusterRole: configsvr，net.port以及其他适用于您的部署的配置，例如net.bindIp，然后启动 3.4 二进制文件：
sharding:
clusterRole: configsvr
net:
port: <port>
bindIp: localhost,<ip address>
storage:
dbpath: <path>
包括适合您的部署的任何其他配置。
- await 该成员恢复到
SECONDARY状态，然后再降级下一个辅助成员。要检查成员的状态，请在mongo shell 中发出rs.status()。
对每个次要成员重复上述步骤。
-
降级主副本集。
-
将mongoShell 连接到主要数据库，并使用rs.stepDown()降低主要数据库并强制选择新的主要数据库：
rs.stepDown()
-
当rs.status()显示主要数据库已降级并且另一个成员已处于
PRIMARY状态时，请关闭已降级的主要数据库并将mongod二进制文件替换为 3.4 二进制文件。 -
使用
--configsvr和--port选项启动 3.4 二进制文件。包括适合您的部署的任何其他配置，例如--bind_ip。
mongod --configsvr --port <port> --dbpath <path> --bind_ip localhost,<ip address>
如果使用configuration file，请更新文件以指定sharding.clusterRole: configsvr，net.port以及其他适用于您的部署的配置，例如net.bindIp，然后启动 3.4 二进制文件：
sharding:
clusterRole: configsvr
net:
port: <port>
bindIp: localhost,<ip address>
storage:
dbpath: <path>
重新启用平衡器。
分片群集组件的降级完成后，重新启用平衡器。