-2

I want to use MongoDB with replication; I created a VM with 2 secondary nodes and 1 arbiter:

  • 1 Primary
  • 2 Secondary
  • 1 Arbiter

I'm trying to understand how this system works, so I have some questions:

1) According to information "If a replica set has an even number of members, add an arbiter." I added an arbiter. But I'm not sure if I have done it correctly. Does this even number apply to secondaries or to all members in total?

2) What does this arbiter doing? I actually don't understand its job.

3) I created public IP addresses for each VM, in order to connect to them from outside. I successfully connected from my application, using this connection string:

mongodb://username:password@vm0:27017,vm1:27017,vm2:27017/dbname?replicaSet=xxx&readPreference=primaryPreferred

I didn't add the arbiter in this connection string but Should I add it or not?

4) When I shut down the primary machine, one of the secondary machine successfully became primary as I expect. There is no problem in this case; but when I shut down the second primary machine my application throws an error. The second secondary node has not become primary - why is this happening?

5) If all VMs are working but I shut down the arbiter, my application again throws an error and I cannot connect to the db. I'm trying this because I'm thinking the case of if there will be something wrong on arbiter machine and it may be shut down in the future because of the maintenance or any other problems.

Maybe because I didn't understand the role of an arbiter; I'm thinking this is wrong but why it is not converting any secondary machine to arbiter? And why when I shut down the arbiter does the whole system not work?

Thanks.

Alexander Chef
  • 378
  • 1
  • 2
  • 13
  • This is really a MongoDB documentation question, not a programming question. And really nothing to do with Azure (or bitnami) either, as written. I removed those tags, accordingly. – David Makogon Dec 25 '17 at 14:28

1 Answers1

1

1) If you have 1 Primary and 2 Secondaries, you have 3 members in your replica set. Therefore you should not be adding an arbiter. You already have an odd number of nodes.

2) An arbiter is a node which doesn't hold data and can't be elected as Primary. It is only used to elect a new Primary if the current Primary goes down.

For example, say you have 1 Primary and 1 Secondary. The replica set has 2 members. If the primary goes down, the replica set will attempt to vote to elect a new Primary. In order for a node to be elected, it needs to win over half the votes. But if the Secondary votes for itself, it will only get 1 out of 2 votes. That's not more than half so it will not be elected. Thus the replica set will not be able to elect a new Primary and your whole replica set will go down.

To fix this, you can add an arbiter to the replica set. This is usually a much smaller machine since it doesn't need to hold data. It just has one job, voting for the Secondary to be the new Primary in the case of elections.

But, since you already have 3 data-bearing nodes, you won't want to add an arbiter. You can read more about arbiters here.

3) You can add arbiters to connection strings but in general you won't need to. Adding the data-bearing nodes is just fine. That's what people usually do.

4) You have 4 members in the replica set. You took down 2 of them. That means there are only 2 votes left. The final secondary won't be able to get more than 50% of the votes so no Primary will be elected.

In general, testing two nodes going down is overkill. You probably want a 3 member replica set. Each member should be in a different availability zone (Availability Set in Azure). If two nodes go down your replica set will be unavailable. But two nodes going down at the same time is very unlikely if all nodes are in different availability zones. So don't worry too much about more than one node going down. If that's a real concern (in most applications it really isn't), you want to make a 5 member replica set.

5) That's weird. This sounds like your replica set might be configured incorrectly. As I said, you don't need an arbiter anyway. So you could just try setting it up again without the arbiter and see if it works. Open a new question if you're still having issues. Make sure to include the output of running rs.status() in your question.

tfogo
  • 1,416
  • 1
  • 14
  • 23
  • Thanks for your answer. For 5th question when I correct machines for 1 primary 1 secondary and 1 arbitrer. Now it is not throwing error anymore. But after that if I shut down arbitrer and primary machine, the system is not selecting secondary as primary and I'm getting server error in my application. I afraid in the future if something will happen to the arbiter machine, like it gets error by itself and if I cannot see this error what will happen? – Alexander Chef Dec 29 '17 at 10:50
  • If 2 out of 3 nodes go down, the replica set will go down. There aren't more than 50% of the votes available to elect a new primary. If just one node (primary, secondary, or arbiter) goes down, your replica set will be fine. These are some basic principles for replica sets, so if you're still unsure about why this is the case, make sure to read the documentation (https://docs.mongodb.com/manual/replication/). – tfogo Dec 29 '17 at 23:12