3

I have a simple mongodb setup in a replicaset, with 1 actual instance and 1 arbiter (to avoid conflicts). This is in anticipation of expanding the replicaset to include more instances as our load increases.

If I access mongodb through the shell, I correctly get the PRIMARY > prompt, and running rs.status() tells me everything is fine and dandy.

I have a node.js server that is accessing the database, using the mongodb-native driver found on github, version 0.9.9-8. However, occasionally it simply breaks down with the following error: Unable to connect to database: Error: no primary server found

The program is given the two adresses for the two instances (normal instance + arbiter), but otherwise neither the program log or mongodb's log gives any clue as to what is wrong. Any help is welcome!

3
  • Should your program know of the existence of the Arbiter? It has nothing to do with actual database work, it just helps to break ties in elections for Primaries. It should be hidden usually.
    – NickW
    Feb 20, 2013 at 10:43
  • I am actually not sure, the mongodb docs don't seem completely clear on whether to include them or not. Feb 20, 2013 at 10:50
  • From my perspective, your program only needs to know two things, where to read/write and who to talk to when it wants to do so. I'd remove the arbiter from the program's "knowledge".. an arbiter won't have any data anyways.
    – NickW
    Feb 20, 2013 at 10:56

2 Answers 2

1

OK, so first, don't give the driver the address of the arbiter, just the primary - there is no reason for the driver to ever talk to the arbiter, it has no data. With just the primary to connect to it will then connect to the primary only and your issue should disappear.

Your set up is another matter - having an arbiter with a single node buys you nothing and actually makes your set less reliable rather than more stable.

Scenario 1: the arbiter goes down/offline

  • The primary is the only node left up and voted for itself
  • 1/2 votes is not a majority, so the primary cannot be elected and becomes a secondary
  • Your set is now down and can't accept writes

Scenario 2: the primary goes down/offline

  • There is no node with data, the arbiter cannot vote for itself
  • 0/2 votes, no actual data nodes available, your set is offline

As you can see, you would actually be better off with just a single primary node - because all the arbiter does is introduce a way for your set to be unavailable when the primary is working just fine. The other option, of course, would be to add a secondary and go to 3 nodes - then you actually get the redundancy benefits of a replica set.

4
  • I am aware that the setup is sub-optimal, but it's an "inherited" system, so for now it has to work in this way. Feb 22, 2013 at 13:08
  • it's not just sub-optimal, it's actually worse than having a single node, so if you simply turned off the arbiter and reconfigured to just a primary you would have a better set up than you do now
    – Adam C
    Feb 22, 2013 at 13:46
  • I removed the arbiter from the replicaset, but it did not change anything. The client still reports "Error: no primary server found", despite the mongo shell showing everything to be in perfect order (though rs.status() and db.serverStatus()) Feb 22, 2013 at 14:00
  • Then I am going to guess that you have configured the driver incorrectly and that it can't connect to the primary at all. Is the client on a different host? If so, run a mongo shell from that host and try to connect to exactly what you have configured in the driver.
    – Adam C
    Feb 22, 2013 at 16:53
0

Thats a quote from http://docs.mongodb.org/manual/core/replication/

The minimum requirements for a replica set include two members with data, 
for a primary and a secondary, and an arbiter. In most circumstances, 
however, you will want to deploy three data members.

You don't meet the defined minimal requirements.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .