1

My server set up is like that:

2 x Servers . The mongoDB has replica set among both servers. Each is one node.

and then I have my node.js server connect to the MongoDB.

What happen was.. when I kill the secondary server. (shutting down the server). The MongoDB at primary still up but the Node.js Server had connection issue with MongoDB then. Even I added the server back, it didn't work. I use mongoose and connect-mongo .

So, what happened? how to shut down Mongo node properly?

Improve this question

2 Answers 2

Reset to default
6

If you have a replica set with 2 nodes, when one node goes down the other will demote itself to secondary. If you aren't connecting with slaveOk true, then you won't be able to read (and in either case you won't be able to write).

This is a safety measure imposed by MongoDB, which requires that a majority (meaning half plus one) of a replica set be able to see one another in order to ensure that a primary can be safely elected. If a majority cannot be seen, the nodes in the minority cannot know whether the "other half" have elected a primary. Having two primaries at the same time would be Very Bad (TM), as that could lead to conflicting updates.

In situations where you only want to run two nodes, you can also run an arbiter to break ties in the case that one node goes down or becomes otherwise invisible to the replica set. An arbiter is a normal mongod process, but does not store any data -- essentially it only participates in elections, and is idle otherwise. In a replica set with 2 "normal" nodes and one arbiter, either one of the two data-holding nodes can go down without losing a majority.

For more, see the MongoDB documentation on replica sets and the documentation on artibers.

Improve this answer
2
  • One thing I don't get is.. I kill the secondary mongo, not the primary one. so, there shouldn't be any voting involve, right? and why it still breaks? :)
    – murvinlai
    Sep 23, 2011 at 6:59
  • Each member of a replica set monitors the others with periodic heartbeat messages -- if at any time the primary member cannot see a majority of the replica set, including itself (note: majority of 2 == 2, so when one is down, by definition there is no majority), it automatically steps down to secondary to avoid conflict scenarios.
    – dcrosta
    Sep 23, 2011 at 12:54
1

If your primary is still primary after you take down the secondary, it's a node's driver issue. Anyway you always should have an arbiter with an even number of replica nodes, the "why" is well documented on mongodb's doc.

In case this is a node.js issue, wich version of node-mongodb-native are you using ? I had some different replicaset issues 2 month ago but there have ben fixed with the latest versions. The last replicaset issue of the driver has ben closed the 9th Sept, you shoud giv it a try with the last tagged version (V0.9.6.18 as i'm writing this)

Improve this answer
3
  • I think i have the arbiter set up. My Mongoose, node and mongo is 2-4 subversion behind. Let me try upgrading it and see if it works. :) thanks.
    – murvinlai
    Sep 23, 2011 at 9:19
  • the only thing that really needs to be up-to-date in your case is the node-mongodb-native driver, mongodb mongoose and node don't really matter as long as they are quite recent
    – Frederik Eychenié
    Sep 23, 2011 at 10:11
  • The primary won't "still [be] primary" if the other node goes down. It will automatically demote itself. It will still be readable if clients are using slaveOk set to true.
    – dcrosta
    Sep 23, 2011 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.