将MongoDB升级到2.4

注意事项¶

注意群集升级过程的以下属性：

• 开始升级之前，请确保配置数据库的文件系统上的可用空间至少是配置数据库数据文件当前使用的空间的4到5倍。

  此外，确保配置数据库中的所有索引均为{v:1}索引。如果关键索引是{v:0}索引，则由于{v:0}格式的已知问题，块拆分可能会失败。{v:0}索引存在于使用MongoDB 2.0或更早版本创建的集群上。

  元数据升级的持续时间取决于执行升级的节点与三个配置服务器之间的网络延迟。确保升级过程和配置服务器之间的等待时间短。

• 在升级过程中，您无法更改集合元数据。例如，在升级过程中，千万不能 执行：

  • sh.enableSharding()，
  • sh.shardCollection()，
  • sh.addShard()，
  • db.createCollection()，
  • db.collection.drop()，
  • db.dropDatabase()，
  • 创建数据库的任何操作，或
  • 以任何方式修改集群元数据的任何其他操作。有关分片命令的完整列表，请参见分片参考。但是请注意，并非“分片参考”页面上的所有命令都会修改集群元数据。

• 升级到2.4并完成升级过程后，请勿在群集中使用2.0 mongod和mongos进程。2.0流程可能会将旧的元数据格式重新引入群集元数据中。

升级后的配置数据库将需要比以前更多的存储空间，以制作config.chunks和config.collections集合的备份和工作副本 。与往常一样，如果存储需求增加，则mongod 可能需要预先分配其他数据文件。请参阅 如何获取有关数据库存储使用的信息？欲获得更多信息。

元数据升级过程¶

更改为分片群集的元数据格式（存储在 config数据库中），在迁移到2.4时需要特殊的元数据升级过程。

执行此过程时，请勿执行修改元数据的操作。有关禁止操作的示例，请参阅将分片群集从MongoDB 2.2升级到MongoDB 2.4。

1. 开始升级之前，请确保配置数据库的文件系统上的可用空间至少是配置数据库数据文件当前使用的空间的4到5倍。

   此外，确保配置数据库中的所有索引均为{v:1}索引。如果关键索引是{v:0}索引，则由于{v:0}格式的已知问题，块拆分可能会失败。{v:0}索引存在于使用MongoDB 2.0或更早版本创建的集群上。

   元数据升级的持续时间取决于执行升级的节点与三个配置服务器之间的网络延迟。确保升级过程和配置服务器之间的等待时间短。

   要检查索引的版本，请使用db.collection.getIndexes()。

   如果任何索引配置数据库的是{v:0}，你应该通过连接到重建这些索引mongos，要么：使用重建所有索引 db.collection.reIndex()方法，或者删除和重建用具体指标db.collection.dropIndex()，然后 db.collection.ensureIndex()。如果需要升级 _id索引{v:1}使用db.collection.reIndex()。

   您可能{v:0}在群集中的其他数据库上具有索引。

2. 关掉平衡器中 分片簇，如在 禁用平衡器。

   可选的

   为了在升级过程中提高安全性，可以使用mongodump或其他备份工具对config数据库进行备份。

3. 确保分片群集中没有任何版本2.0 mongod或 mongos进程仍处于活动状态。自动升级过程会检查2.0个过程，但是网络可用性可能会阻止进行明确的检查。在停止或升级2.0版mongos 进程后，请等待5分钟，以确认所有进程仍未激活。

4. mongos通过configDB指向分片群集的配置服务器并带有--upgrade 选项来启动一个2.4 进程 。升级过程发生在该过程成为守护程序之前（即之前） --fork。

   您可以将现有mongos实例升级 到2.4，也可以启动 可以访问所有配置服务器的新mongos实例（如果需要避免重新配置生产）mongos。

   mongos使用类似于以下内容的命令启动：

   复制

   mongos --configdb <config servers> --upgrade
   

   如果没有该--upgrade选项，mongos则在升级过程完成之前，进程将无法启动2.4 。

   升级将防止在升级过程中发生任何块移动或分裂。如果有很多分片集合，或者其他失败的进程持有过时的锁，则获取所有集合的锁可能需要几秒钟或几分钟的时间。请参阅日志以获取进度更新。

5. 该mongos过程成功启动后，升级即告完成。如果该mongos过程无法启动，请检查日志以获取更多信息。

   如果mongos在升级过程中终止或失去与配置服务器的连接，则可以始终安全地重试升级。

   但是，如果在短关键部分内升级失败，mongos将退出并报告升级将需要手动干预。要继续升级过程，您必须遵循“关键部分中断”过程后的 “ 重新同步”。

   可选的

   如果mongos日志显示升级正在等待升级锁，则先前的升级过程可能仍处于活动状态或已异常结束。15分钟没有任何远程活动后，mongos将强制升级锁定。如果可以验证没有正在运行的升级过程，则可以连接到2.2 mongos进程并手动强制锁定：

   复制

   mongo <mongos.example.net>
   

   复制

   db.getMongo().getCollection("config.locks").findOne({ _id : "configUpgrade" })
   

   如果在process本文档的字段中指定的过程可验证地处于脱机状态，请运行以下操作以强制锁定。

   复制

   db.getMongo().getCollection("config.locks").update({ _id : "configUpgrade" }, { $set : { state : 0 } })
   

   mongos如果您对另一个升级操作的活动有任何疑问，则等待验证锁是否处于非活动状态总是更安全的。除了之外 configUpgrade，mongos还可能需要等待特定的收集锁。不要强行使用特定的收集锁。

6. 升级和重新启动其他mongos的分片群集中的过程，而不该--upgrade 选项。

   有关更多信息，请参见升级分片群集组件。

7. 重新启用平衡器。现在，您可以执行修改集群元数据的操作。

升级后，请勿将2.0版MongoDB进程引入分片群集。这样可以将旧的元数据格式重新引入到配置服务器中。通过此升级过程进行的元数据更改将有助于防止由于MongoDB的未来版本中的跨版本不兼容而引起的错误。

关键部分中断后重新同步¶

在将更改应用于元数据的升级的短暂关键阶段中，网络中断不太可能但有可能阻止所有三台配置服务器验证或修改数据。如果发生这种情况，则必须重新同步配置服务器，并且在启动新mongos进程时可能会出现问题。分片群集 将保持可访问性，但是要避免所有群集元数据更改，直到重新同步配置服务器为止。更改元数据的操作包括：添加分片，删除数据库和删除集合。

要重新同步配置服务器：

1. 关闭分片群集中的平衡器，并停止所有元数据操作。如果您正在升级过程中（将分片群集从MongoDB 2.2升级到MongoDB 2.4），则已经禁用了均衡器。

2. 关闭三个配置服务器中的两个，最好关闭configDB字符串中列出的最后两个。例如，如果您的configDB 字符串是configA:27019,configB:27019,configC:27019，请关闭 configB和configC。关闭最后两个配置服务器可确保大多数mongos实例对集群元数据的访问不会中断。

3. mongodump活动配置服务器（configA）的数据文件。

4. 将已停用的配置服务器（configB 和configC）的数据文件移动到备份位置。

5. 创建新的空数据目录。

6. 通过--dbpath 指向现在为空的数据目录并--port 指向备用端口（例如27020）来重新启动禁用的配置服务器。

7. 用于mongorestore将禁用文档上的数据文件从活动配置服务器（configA）重新填充到新端口（configB:27020,configC:27020）上重新启动的配置服务器。这些配置服务器现在已重新同步。

8. 在旧端口上重新启动已还原的配置服务器，并将端口重置回旧设置（configB:27019和configC:27019）。

9. 在某些情况下，连接池可能会导致虚假故障，因为mongos只有在尝试使用后才禁用旧连接。2.4修复了这个问题，但要避免在2.2版本这个问题，你可以重新启动所有mongos实例（一个接一个，以避免停机时间），然后使用rs.stepDown()重新启动每个碎片的方法之前副本集 初选。

10. 分片群集现在已完全重新同步；但是，在再次尝试升级过程之前，必须使用2.2版手动重置升级状态mongos。通过连接到2.2开始mongos与mongo 外壳：

    复制

    mongo <mongos.example.net>
    

    然后，使用以下操作重置升级过程：

    复制

    db.getMongo().getCollection("config.version").update({ _id : 1 }, { $unset : { upgradeState : 1 } })
    

11. 最后，重试升级过程，如 将分片群集从MongoDB 2.2升级到MongoDB 2.4中一样。

基本降级和升级¶

除非如下所述，否则在2.2和2.4之间移动是一种直接替代：

• mongod使用以下--shutdown选项停止现有的：

  复制

  mongod --dbpath /var/mongod/data --shutdown
  

  /var/mongod/data用您的MongoDB 替换dbPath。

• mongod使用相同的dbPath设置启动新进程 ，例如：

  复制

  mongod --dbpath /var/mongod/data
  

  /var/mongod/data用您的MongoDB 替换dbPath。

创建2dsphereor text索引后降级到2.2¶

如果您在运行2.4 实例时创建了索引2dsphere或创建了text索引，则mongod可以通过2.2 mongod使用以下--upgrade选项启动随时降级：

mongod --dbpath /var/mongod/data/ --upgrade

然后，您将需要使用删除所有现有 索引2dsphere或text索引db.collection.dropIndex()，例如：

db.records.dropIndex( { loc: "2dsphere" } )
db.records.dropIndex( "records_text" )

对升级/降级操作进行故障排除¶

如果您不使用--upgrade，当您尝试启动2.2 mongod并创建了 2dsphere或text索引时，mongod将返回以下消息：