3

The official mongodb documentation states to use three config servers. They say its for redudancy, because 1 server would be a point of failure.... but why not 2? in a production sharded cluster, if I have 1 shard, I shouldn't need more than 2, right? Is one config server only meant to handle 1 shard? so, if the minimum is 2 shards, then at least I should have 3?

5

Config servers are a special case, you can use one (for testing), or three and that's it. They are not a replica set, at least not yet, that might change in the future, see SERVER-1448.

Go and (re)read the first two paragraphs here - note the piece about them not being a replica set is explicitly mentioned. I will pick out some other relevant points:

Config servers use a two-phase commit to ensure immediate consistency and reliability

to ensure redundancy and safety in production, you should always use three

The first part gives you a hint about why 3 are needed, the second part is telling, particularly in terms of the safety aspect (redundancy is obvious - you have 3 copies of the data).

With how the 2 phase commit is implemented, all three config servers must receive (and acknowledge) a change for it to be considered successful. That's the safety piece - all three must be in a quorum and have the same data (there are regular checks), and that is why it is three config servers required exactly (for now). When you run with just one for testing, this can't happen, and your cluster meta data is essentially at risk, hence using just one is for testing purposes only.

0

The document does not say why we need 3 config servers. But it is recommended to use odd number of mongods in each shard, maybe for quick elect? I think it is the same reason why we need odd number of config servers. I am not sure.

Each config server can handle lots of shards. config server does not consume too much resource, such as disk. Because config server store config info, meta data, not the user data. So you can use one config server in your deployment for lots of shards. But in production, for redundancy, it is suggested to use 3 config servers. each config server has nearly the same data copy.

  • Is it recommended to use odd number of mongods in each shard?? I thought the minimum was two shards... – M.R. Feb 5 '15 at 16:49
  • (1)Please see the doc docs.mongodb.org/manual/core/replica-set-architectures It says that an odd number of members ensures that the replica set is always able to elect a primary. If you have an even number of members, add an arbiter to get an odd number. Arbiters do not store a copy of the data and require fewer resources. Each shard always should be a replication set in production for reliability. (2) In my production, I just have one shard now. But in the future, we may add new shard, depending on the data size. – BAE Feb 5 '15 at 18:34
  • That explains the odd number for the actual shards - but what about the config servers? – M.R. Feb 5 '15 at 20:07
  • The odd number also doesn't make complete sense. If I have 3 members, and 1 dies, then I have only 2 left - wouldn't I get a tie between the two? – M.R. Feb 5 '15 at 20:07
  • According to my experience, one more config server does not consume too much space. – BAE Feb 5 '15 at 20:42
0

Why it always 1 or more than 2? Obvious answer is split brain problem. Any instance or programs that falls under replication would face this issue. Read more this

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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