将分片群集升级到 3.4
在本页面
Note
-
从 MongoDB 3.4.21 开始，MongoDB 3.4 系列删除了对 Ubuntu 16.04 PPCLE 的支持。
-
对于支持 Ubuntu 16.04 POWER/PPC64LE 的 MongODB Enterprise 早期版本：
由于 Ubuntu 16.04 for POWER 的glibc软件包的较早版本中存在锁定清除错误，因此在运行 MongoDB 之前，必须将glibc软件包升级到至少glibc 2.23-0ubuntu5。使用glibc软件包的较旧版本的系统会由于随机内存损坏而导致数据库服务器崩溃和行为异常，并且不适合 MongoDB 的生产部署
Important
在尝试任何升级之前，请熟悉本文档的内容。
如果您需要有关升级到 3.4 的指导，请MongoDB 提供主要版本升级服务以帮助确保平稳过渡而不会中断您的 MongoDB 应用程序。
升级建议和清单
升级时，请考虑以下事项：
升级版本路径
要将现有的 MongoDB 部署升级到 3.4，必须运行 3.2 系列发行版。
要从 3.2 系列之前的版本升级，必须先升级主要版本，直到升级到 3.2 系列。例如，如果您运行的是 3.0 系列，则必须在3.2 之前才能升级到 3.4.
Preparedness
开始升级之前，请参阅MongoDB 3.4 中的兼容性更改文档，以确保您的应用程序和部署与 MongoDB 3.4 兼容。开始升级之前，请解决部署中的不兼容性。
在升级 MongoDB 之前，请务必先在临时环境中测试应用程序，然后再将升级部署到生产环境中。
Downgrade Consideration
一旦升级到 3.4，就不能降级到 3.2.7 或更早的版本。您只能降级到 3.2.8 或更高版本。
避免重新配置包含不同 MongoDB 版本成员的副本集，因为验证规则在 MongoDB 版本之间可能有所不同。
mongos 和 mongod 实例的早期版本
3.4 版mongos实例无法连接到mongod实例的早期版本。
3.2 和更早版本的mongo shell 与 3.4 群集不兼容。
Prerequisites
-
-
3.2 版或更高版本
-
要将分片群集升级到 3.4，群集的所有成员必须至少为 3.2 版。升级过程将检查群集的所有组件，如果有任何组件运行的版本早于 3.2，则会发出警告。
-
-
-
将服务器配置为副本集(CSRS)
-
从 3.4 开始，不再支持将已弃用的镜像mongod实例用作配置服务器(SCCC)。
-
在将分片群集升级到 3.4 之前，必须将配置服务器从 SCCC 转换为副本集(CSRS)。要将配置服务器从 SCCC 转换为 CSRS，请参见将配置服务器升级到副本集。
-
-
备份
config数据库 -
*可选，但建议.*作为预防措施，在升级分片群集之前，请备份
config数据库。
-
下载 3.4 二进制文件
使用软件包 Management 器
如果从 MongoDB apt，yum，dnf或zypper存储库安装了 MongoDB，则应使用程序包 Management 器升级到 3.4.
遵循适用于您的 Linux 系统的3 .4 安装说明。这将涉及为新版本添加存储库，然后执行实际的升级过程。
手动下载 3.4 Binaries
如果尚未使用包 Management 器安装 MongoDB，则可以从MongoDB 下载中心手动下载 MongoDB 二进制文件。
有关更多信息，请参见3 .4 安装说明。
Upgrade Process
禁用平衡器。
如禁用平衡器所述禁用平衡器。
升级配置服务器。
如果配置服务器是副本集：
mongod --configsvr --port <port> --dbpath <path>
如果使用configuration file，则更新文件以指定sharding.clusterRole: configsvr和net.port并启动 3.4 二进制文件：
sharding:
clusterRole: configsvr
net:
port: <port>
storage:
dbpath: <path>
包括适合您的部署的任何其他配置。
- await 该成员恢复到
SECONDARY状态，然后再升级下一个辅助成员。要检查成员的状态，请在mongo shell 中发出rs.status()。
对每个次要成员重复上述步骤。
-
降级主副本集。
-
将mongoShell 连接到主要数据库，并使用rs.stepDown()降低主要数据库并强制选择新的主要数据库：
rs.stepDown()
-
当rs.status()显示主要数据库已降级并且另一个成员已处于
PRIMARY状态时，请关闭已降级的主要数据库并将mongod二进制文件替换为 3.4 二进制文件。 -
使用
--configsvr和--port选项启动 3.4 二进制文件：
mongod --configsvr --port <port> --dbpath <path>
如果使用configuration file，则更新文件以指定sharding.clusterRole: configsvr和net.port并启动 3.4 二进制文件：
sharding:
clusterRole: configsvr
net:
port: <port>
storage:
dbpath: <path>
包括适合您的部署的任何其他配置。
升级碎片。
一次升级一个碎片。如果这些分片是副本集，则对于每个分片：
mongod --shardsvr --port <port> --dbpath <path>
如果使用configuration file，请将文件更新为包含sharding.clusterRole: shardsvr和net.port并开始：
sharding:
clusterRole: shardsvr
net:
port: <port>
storage:
dbpath: <path>
包括适合您的部署的任何其他配置。
- await 该成员恢复到
SECONDARY状态，然后再升级下一个辅助成员。要检查成员的状态，您可以在mongo shell 中发出rs.status()。
对每个次要成员重复上述步骤。
- 降级主副本集。
将mongoShell 连接到主要数据库，并使用rs.stepDown()降低主要数据库并强制选择新的主要数据库：
rs.stepDown()
-
当rs.status()显示主要数据库已卸任，另一个成员已处于
PRIMARY状态时，请升级已卸任的主要数据库： -
关闭逐步降低的主数据库，并将mongod二进制文件替换为 3.4 二进制文件。
- 使用
--shardsvr和--port命令行选项启动 3.4 二进制文件。
- 使用
mongod --shardsvr --port <port> --dbpath <path>
如果使用configuration file，则更新文件以指定sharding.clusterRole: shardsvr和net.port并启动 3.4 二进制文件：
sharding:
clusterRole: shardsvr
net:
port: <port>
storage:
dbpath: <path>
包括适合您的部署的任何其他配置。
升级 mongos 实例。
将每个mongos实例替换为 3.4 二进制文件，然后重新启动。包括适合您的部署的任何其他配置。
Note
mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3>
重新启用平衡器。
使用 3.4 mongo shell，如启用平衡器中所述重新启用平衡器。
3.2 和更早版本的mongo shell 与 3.4 群集不兼容。
启用向后不兼容的 3.4 功能。
此时，您可以在没有 3.4 不兼容的功能和 3.2 的情况下运行 3.4 二进制文件。
要启用这些 3.4 功能，请将功能兼容版本设置为 3.4.
Warning
启用这些向后不兼容的功能可以降级过程复杂化。有关详细信息，请参见删除 3.4 不兼容的功能。
建议升级后，允许您在不启用这些功能的情况下运行部署，并且要在预热期内确保降级的可能性最小。如果您确信降级的可能性很小，请启用这些功能。
在mongos实例上，在admin数据库中运行setFeatureCompatibilityVersion命令：
db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )
此命令必须执行对内部系统集合的写入。如果由于某种原因该命令未成功完成，则可以安全地在mongos上重试该命令，因为该操作是幂等的。
其他升级步骤
-
要升级独立版本，请参阅将独立版升级到 3.4。
-
要升级副本集，请参阅将副本集升级到 3.4。