Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Currently I've got server A and server B running with the following mongod instances:

Server A

  1. mongod server (usually PRIMARY)
  2. mongod arbiter

Server B

  1. mongod server (usually SECONDARY)

When server A goes down, server B fails to elect itself as primary to take everything over. As such, my entire application goes offline as the database is unavailable.

My question is, without increasing the amount of physical servers, how can I make sure that server B takes over properly when server A goes down?

Would the following be a good idea?

Server A

  1. mongod server 1A
  2. mongod server 2A
  3. mongod arbiterA

Server B

  1. mongod server 1B
  2. mongod server 2B
  3. mongod arbiterB

Where I have not added an arbiter to B because that would make the total number of servers even. The question is: is this the most efficient way to let server B take over when server A powers off? Or can I remove some servers to save RAM/CPU/HDD?

share|improve this question

2 Answers 2

It's not really effective to have arbiters on the same machine as your mongod processes. Do you have a third unrelated server to run the Arbiter on?

(Documented here: http://www.mongodb.org/display/DOCS/Replica+Set+Tutorial#ReplicaSetTutorial-Runningwithtwonodes)

Running multiple mongod processes on the same server is going to cause performance problems. Besides, having two usable mongod processes and an arbiter on the same machine means that if the two physical servers become disconnected from one-another, they'll each elect a local Primary.

share|improve this answer
    
So, for a replicaset to be effective, one has to have at least 3 physical servers? I wish the documentation would state this. Unfortunately I only have 2 servers at the moment and would like to stick with that due to cost constraints. –  Tom Jun 1 '12 at 9:47
    
I find that they do (mongodb.org/display/DOCS/Replica+Sets+-+Basics), but I suppose that it can be misinterpreted. If it makes you feel better, the Arbiter process is very lightweight, so if a VM was available to supplement, that would be perfect. –  gWaldo Jun 1 '12 at 10:38
1  
I will take a pass at making this more clear in the documentation and send a pull request. –  gWaldo Jun 1 '12 at 10:39
1  
Turns out that that is the old part of the documentation, which is being deprecated. The new stuff is under docs.mongodb.org/manual/replication. I've forked, made some changes, and submitted a pull request to the github.com/mongodb/docs repo. I expect that they'll move on it within a couple days. –  gWaldo Jun 3 '12 at 21:15
1  
You can run three mongod processes on the same physical host (listening on different ports), but all three will compete for the same resources (memory, disk, network), and only serve to slow each other down. The only good reason to do so is to get a grasp of replica sets, or possibly initial tests of slave-reads within a replica set. –  gWaldo Nov 6 '12 at 16:46

The most efficient way to have Server B take over when A powers off is to move your current arbiter to B. However, that would mean that A would stop being primary if B failed because it would be unable to form a majority.

There are two options - have another arbiter instance ready to go on A/B and reconfigure the set when there is a failure to add that into the set and remove the other arbiter, or relaunch A/B as a standalone mongod outside of a replica set while the other is down and reconfigure once things are healthy again.

With 2 machines you will consistently run into this problem of having to manually intervene to get the set back up. Every automatic solution I can think of involves having another machine.

share|improve this answer
    
What about my suggestion? Each server having 2 normal mongo instances and 1 arbiter? I don't see why having two servers would be such an issue. –  Tom May 28 '12 at 11:21
    
If each has 2 instances and one arbiter, you end up with 6 total, with 3 votes each, no single machine can form a majority. It's the same as running with one instance on each - you don't gain anything and just use up resources for no reason. –  Adam C May 28 '12 at 14:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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