将 MongoDB 升级到 3.0
在本页面
通常，从 MongoDB 2.6 升级到 3.0 是二进制兼容的“嵌入式”升级：关闭mongod实例，并用运行 3.0 的mongod实例替换它们。 但是 ，在尝试进行任何升级之前，请熟悉本文档的内容，尤其是升级分片集群的过程。
如果您需要有关升级到 3.0 的指导，请MongoDB 提供咨询帮助确保平稳过渡而不会中断您的 MongoDB 应用程序。
升级建议和清单
升级时，请考虑以下事项：
Upgrade Requirements
要将现有的 MongoDB 部署升级到 3.0，必须运行 2.6. 如果您正在运行 2.6 之前的 MongoDB 版本，则必须*升级到 2.6，然后再升级到 3.0. 有关从 2.4 升级到 2.6 的过程，请参见升级到 2.6。升级到 MongoDB 2.6 后，您不能**降级到 MongoDB 2.4 之前的任何版本。
如果您现有的 MongoDB 部署已经通过身份验证和授权运行，则用户数据模型authSchema必须至少为版本 3.要验证现有authSchema的版本，请参阅MongoDB 2.4 用户模型已删除。要升级authSchema版本，请参见升级授权数据。
Preparedness
在升级 MongoDB 之前，请务必先在临时环境中测试应用程序，然后再将升级部署到生产环境中。
MongoDB 3.0 中的某些更改需要手动检查和干预。开始升级之前，请参阅MongoDB 3.0 中的兼容性更改文档，以确保您的应用程序和部署与 MongoDB 3.0 兼容。开始升级之前，请解决部署中的不兼容性。
Downgrade Limitations
升级到 MongoDB 3.0 后，您不能将其降级到低于 2.6.8 的版本。
如果您升级到 3.0 并已运行authSchemaUpgrade，则不能在不禁用--auth或还原升级前备份的情况下**降级到 2.6，因为authSchemaUpgrade会丢弃 2.6 中使用的MONGODB-CR凭据。参见升级现有的 MONGODB-CR 用户以使用 SCRAM-SHA-1。
升级 MongoDB 流程
将独立 mongod 实例升级到 MongoDB 3.0
以下步骤概述了将独立的mongod从 2.6 版本升级到 3.0 的过程。要从 2.4 版本升级到 3.0，请先升级到 2.6 版 首先，然后使用以下过程从 2.6 升级到 3.0.
Upgrade Binaries
如果从 MongoDB apt，yum或zypper存储库安装了 MongoDB，则应使用程序包 Management 器升级到 3.0. 遵循适用于您的 Linux 系统的installation instructions。这将涉及为新版本添加存储库，然后执行实际升级。
否则，您可以手动升级 MongoDB：
下载 3.0 二进制文件。
从MongoDB 下载页面下载 3.0 系列最新版本的二进制文件。有关更多信息，请参见Install MongoDB。
替换 2.6 二进制文件。
关闭您的mongod实例。将现有的二进制文件替换为 3.0 mongod二进制文件，然后重新启动mongod。
将独立存储引擎更改为 WiredTiger
要将独立mongod实例的存储引擎更改为 WiredTiger，请参见将 Standalone 更改为 WiredTiger。
将副本集升级到 3.0
Prerequisites
-
如果操作日志包含由 2.2.1 之前的 MongoDB 版本生成的条目，则必须先等到更高版本覆盖这些条目，然后才能升级到 MongoDB 3.0. 有关更多信息，请参见副本集 Oplog 格式更改
-
副本集配置MongoDB 3.0 中更严格的验证可能会使以前有效的副本集配置无效，从而阻止了副本集在 MongoDB 3.0 中启动。有关更多信息，请参见副本集配置验证。
-
您必须将所有副本集成员都运行 2.6 版，然后才能将其升级到 3.0 版。要从 MongoDB 早期版本将副本集的所有成员升级到版本 2.6 * first *升级副本集，然后按照从 MongoDB 2.6 升级到 3.0 的过程进行操作。
Upgrade Binaries
您可以使用“滚动”升级从 MongoDB 2.6 升级到 3.0，以通过在其他成员可用时分别升级成员来最大程度地减少停机时间：
升级副本集的辅助成员。
通过关闭mongod并将 2.6 二进制文件替换为 3.0 二进制文件，一次升级一组secondary成员。升级mongod实例后，请 await 成员恢复到SECONDARY状态，然后再升级下一个实例。要检查成员的状态，请在mongo shell 中发出rs.status()。
降级主要副本集。
在mongoShell 程序中使用rs.stepDown()来降低primary并将其设置为failover。 rs.stepDown()加快了故障转移过程，比直接关闭主数据库更可取。
升级主数据库。
当rs.status()显示主要数据库已降级，而另一个成员已处于PRIMARY状态时，请关闭先前的主要数据库并将mongod二进制文件替换为 3.0 二进制文件并启动新实例。
副本集故障转移不是即时的，并且将使该集不可用，直到故障转移过程完成为止。这可能需要 30 秒或更长时间：在计划的维护时段内计划升级过程。
将副本集存储引擎更改为 WiredTiger
要将副本集的存储引擎更改为 WiredTiger，请参见将副本集更改为 WiredTiger。
将分片群集升级到 3.0
如果集群的所有成员当前正在运行 2.6 实例，则仅将分片集群升级到 3.0. 运行 2.4 的分片群集的唯一受支持的升级路径是通过 2.6. 升级过程将检查群集的所有组件，如果有任何组件正在运行版本 2.4，则会产生警告。
Considerations
升级过程不需要任何停机时间。但是，在升级分片群集时，请确保 Client 端不对集合元数据进行更改。例如，在升级期间，请 不要 执行以下任何操作：
-
创建数据库的任何操作
-
任何以任何方式修改群集元数据的其他操作。有关分片命令的完整列表，请参见Sharding Reference。但是请注意，并非Sharding Reference页上的所有命令都会修改群集元数据。
升级分片群集
*可选，但建议.*作为预防措施，在升级分片群集之前，请备份config数据库。
禁用平衡器。
升级群集的元数据。
使用configDB指向群集的配置服务器并使用--upgrade选项启动一个 3.0 mongos实例。
要使用--upgrade选项运行mongos，可以将现有mongos实例升级到 3.0，或者，如果需要避免重新配置生产mongos实例，则可以使用可以访问所有配置服务器的新 3.0 mongos。
要升级元数据，请运行：
mongos --configdb <configDB string> --upgrade
您可以包括--logpath选项，以将日志消息输出到文件，而不是标准输出。还包括启动群集中的mongos实例所需的任何其他选项，例如--sslOnNormalPorts或--sslPEMKeyFile。
3.0 mongos将输出参考日志消息。
<timestamp> I SHARDING [mongosMain] MongoS version 3.0.0 starting: ...
...
<timestamp> I SHARDING [mongosMain] starting upgrade of config server from v5 to v6
<timestamp> I SHARDING [mongosMain] starting next upgrade step from v5 to v6
<timestamp> I SHARDING [mongosMain] about to log new metadata event: ...
<timestamp> I SHARDING [mongosMain] checking that version of host ... is compatible with 2.6
...
<timestamp> I SHARDING [mongosMain] upgrade of config server to v6 successful
...
<timestamp> I SHARDING [mongosMain] distributed lock 'configUpgrade/...' unlocked.
<timestamp> I - [mongosMain] Config database is at version v6
mongos将在--upgrade流程完成后退出。
升级将防止在升级过程中发生任何块移动或分裂。如果数据文件具有许多分片的集合，或者失败的进程持有过时的锁，则获取所有集合的锁可能需要几秒钟或几分钟的时间。查看日志以获取进度更新。
确保 mongos --upgrade 过程成功完成。
mongos将在元数据升级过程完成后退出。如果成功，该过程将记录以下消息：
<timestamp> I SHARDING [mongosMain] upgrade of config server to v6 successful
...
<timestamp> I - [mongosMain] Config database is at version v6
成功升级后，重新启动mongos实例。如果mongos无法启动，请检查日志以获取更多信息。
如果mongos实例在升级期间失去与配置服务器的连接，或者升级失败，则可以始终安全地重试升级。
将其余的 mongos 实例升级到 3.0.
无需分片群集中的其他mongos实例，就可以在没有--upgrade选项的情况下升级并重新启动**。
成功升级* all * mongos个实例后，可以 continue 升级分片群集中的其他组件。
升级配置服务器。
成功升级* all * mongos个实例后，请升级所有 3 个mongod配置服务器实例，而mongos --configdb参数中列出的* first 配置服务器要升级 last *。
升级碎片。
一次升级每个分片，在运行replSetStepDown之前先升级mongod个从属，并升级每个分片的主。
重新启用平衡器。
分片群集组件的升级完成后，重新启用平衡器。
将分片群集存储引擎更改为 WiredTiger
对于 MongoDB 3.0 中的分片群集，您可以选择更新分片以使用 WiredTiger 存储引擎，并使配置服务器使用 MMAPv1.如果将配置服务器更新为使用 WiredTiger，则必须将所有三个配置服务器更新为使用 WiredTiger。
要将分片群集更改为使用 WiredTiger，请参见将分片群集更改为 WiredTiger。
升级现有的 MONGODB-CR 用户以使用 SCRAM-SHA-1
升级二进制文件后，请参阅升级到 SCRAM有关SCRAM-SHA-1升级方案的详细信息。
一般升级步骤
除本页中所述的 外，在 2.6 和 3.0 之间移动是一种直接替代：
停止现有 mongod 实例。
例如，在 Linux 上，使用--shutdown选项运行 2.6 mongod，如下所示：
mongod --dbpath /var/mongod/data --shutdown
将/var/mongod/data替换为您的 MongoDB dbPath。另请参见停止 mongod 进程，以了解停止mongod实例的替代方法。
启动新的 mongod 实例。
mongod --dbpath /var/mongod/data
将/var/mongod/data替换为您的 MongoDB dbPath。