Clever Geek Handbook

Exception when performing a restart from a replica set to offline

I am currently experimenting with the MongoDB Replica Set Engine. I already have a separate standalone Mongo server with a main database of about 20GB.

I decided to convert this mongo server to a primary replica server and then added a second machine with similar configuration (but newer version of mongo) as a secondary replica set server. This works great, all data is replicated to the secondary as expected.

But I would like to perform some operations on data changes (because for some reason my data model has changed and I need to rename some properties, for example, or convert references to a simple ObjectId, some similar stuff). At the same time, I would like to update the first server with the old version (2.4) to the latest version available (2.6).

So I decided to follow the instructions on the MongoDB website to perform maintenance on the replica set members .

  • shutdown the secondary server. (OK)

  • reboot the server as standalone on a different port (both servers usually run on 27017)

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

And then the server never reboots correctly and I get this:

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:

What am I doing wrong? Note that at this time the first server is still running as the main unit.

Thanks in advance!

+3


source to share


1 answer


I believe you are pushing a bug in VMWare here ( can you confirm that you are using VMWare VM? Confirmed ). I've seen it confirmed on Ubuntu and Fedora. The error causes chunks of previous data not to be zeroed out when creating MongoDB namespace files (not always, but sometimes). This previous data essentially shows up as corruption in the namespace files and leads to the statement you saw.

To work around the issue, MongoDB versions 2.4.12 and 2.6.5+ will be fixed as part of SERVER-15369 . The OS / Kernel layer fix will eventually trickle down from the kernel bug and Ubuntu patch, but it may take a while to actually be available as an official update (hence the need for a temporary change in MongoDB).

The issue will only show up when upgrading to version 2.6 due to additional check added to this version not present in version 2.4, however corruption is still present, just not reported version 2.4

If you still have a primary startup and it has no corruption, I would recommend syncing a secondary that is not on the VMWare VM and / or backing up your files as soon as possible for security. there is no automatic way to fix this damage right now.



You can also view 2.6.5 after its release ( 2.6.5 rc4 is available as of writing, which includes a fix). You will still have to resynchronize this version with your good source to create a working secondary system, but at least it will not have ns file corruption.

Updates:

+6


source






More articles:


All Articles