执行从副本集重新启动到独立时的异常

时间：2014-10-03 12:52:29

标签： mongodb exception database-replication

我目前正在尝试使用MongoDB副本集机制。 我已经有一个工作独立的Mongo服务器，其主数据库大约有20GB的数据。

我决定将此mongo服务器转换为主副本集服务器，然后添加具有类似配置的第二台计算机（但是更新的mongo版本），作为辅助副本集服务器。 这很好，所有数据都按预期复制到辅助数据。

但我想对数据执行一些更改操作（因为不知何故，我的数据模型已经改变，我需要，例如重命名一些属性，或者将引用转换为简单的ObjectId，有些类似的东西）。与此同时，我想将第一台具有旧版本（2.4）的服务器更新为最新版本（2.6）。

所以我决定按照MongoDB网站上的说明perform maintenance on replica set members。

  1. 关闭辅助服务器。 （OK）

  2. 在另一个端口上独立重启服务器（两台服务器通常在27017上运行）

    mongod --dbpath / my / database / path --port 37017

    3. 然后，服务器永远不会正确重启，我明白了：

    2014-10-03T08:20:58.716+0200 [initandlisten] opening db:  myawesomedb
2014-10-03T08:20:58.735+0200 [initandlisten] myawesomedb Assertion failure _name == nsToDatabaseSubstring( ns ) src/mongo/db/catalog/database.cpp 472
2014-10-03T08:20:58.740+0200 [initandlisten] myawesomedb 0x11e6111 0x1187e49 0x116c15e 0x8c2208 0x765f0e 0x76ab3f 0x76c62f 0x76cedb 0x76d475 0x76d699 0x7fd958c3eec5 0x764329 
 /usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0x11e6111]
 /usr/bin/mongod(_ZN5mongo10logContextEPKc+0x159) [0x1187e49]
 /usr/bin/mongod(_ZN5mongo12verifyFailedEPKcS1_j+0x17e) [0x116c15e]
 /usr/bin/mongod(_ZN5mongo8Database13getCollectionERKNS_10StringDataE+0x288) [0x8c2208]
 /usr/bin/mongod(_ZN5mongo17checkForIdIndexesEPNS_8DatabaseE+0x19e) [0x765f0e]
 /usr/bin/mongod() [0x76ab3f]
 /usr/bin/mongod(_ZN5mongo14_initAndListenEi+0x5df) [0x76c62f]
 /usr/bin/mongod(_ZN5mongo13initAndListenEi+0x1b) [0x76cedb]
 /usr/bin/mongod() [0x76d475]
 /usr/bin/mongod(main+0x9) [0x76d699]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fd958c3eec5]
 /usr/bin/mongod() [0x764329]
2014-10-03T08:20:58.756+0200 [initandlisten] exception in initAndListen: 0 assertion src/mongo/db/catalog/database.cpp:472, terminating
2014-10-03T08:20:58.757+0200 [initandlisten] dbexit:

    我做错了什么？ 请注意，此时，第一台服务器仍作为主要成员运行。

    提前致谢！

1 个答案:

答案 0 :(得分：6)

我相信你在VMWare中遇到bug（你能确认你使用的是VMWare VM吗？ 确认） - 我看到它确认了到目前为止Ubuntu和Fedora。在创建MongoDB命名空间文件时（不总是，但有时），该错误会导致以前的数据不被清零。之前的数据基本上表现为命名空间文件中的损坏，并导致您看到的断言。

要解决此问题，MongoDB版本2.4.12和2.6.5+中将发布一个修复程序作为SERVER-15369的一部分。操作系统/内核级别修复程序最终会从内核错误和Ubuntu修补程序中渗透，但这可能需要一些时间才能真正作为官方更新提供（因此需要在过渡期间更改MongoDB本身的变通方法）。 / p>

只有在升级到2.6时才会出现问题，因为2.4中没有添加到该版本的附加检查，但是仍然存在损坏，只是没有在2.4版本上报告

如果你仍然有主要运行，并且它没有损坏，我建议同步一个不在VMWare VM上的辅助设备和/或为了安全而尽快备份你的文件 - 有现在没有自动修复此损坏的方法。

一旦发布，您也可以使用版本2.6.5（编写此版本时可以使用2.6.5 rc4，其中包括修复）。您仍然需要从您的良好来源重新同步该版本以创建一个有效的辅助，但至少不会损坏ns文件。

更新：

相关问题
最新问题