Re: Where Should Config Servers Run?

From: Chris Cunningham <chris.cunningham@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Mon, 9 May 2016 17:39:51 -0700 (PDT)
Why ads?
 

Hello,


There should be very careful consideration of Config Servers deployment to 
ensure smooth operation of your sharded cluster. It is highly recommended 
to deploy each Config Server is on its own separate machine.


Config Servers are vital to the operation of your sharded cluster and in 
the event that they become corrupt or inconsistent, it can be very 
difficult to resolve successfully. Without clean, working Config Servers, 
the cluster may not be able to determine where data in a sharded collection 
is stored, severely disrupting the operation of the cluster. So ensuring 
they are running without any problems is essential to your operations.


Currently, there are two possible ConfigServer deployment in MongoDB:

   - Pre-3.2: Sync Cluster Connection Config (SCCC) mode. This is the 
   legacy config server mode that uses three mirrored, separate servers 
   <https://docs.mongodb.com/v3.0/core/sharded-cluster-config-servers/>, 
   and do not form a replica set.


   - 3.2: Config Server as Replica Set (CSRS) 
   <https://docs.mongodb.com/manual/core/sharded-cluster-config-servers/#replica-set-config-servers>
    mode. This is the currently recommended deployment configuration where 
   the config servers are a replica set. In this setting, the maximum number 
   of Config Servers is increased to the maximum number of nodes in a 
   replica set (50) 
   <https://docs.mongodb.com/manual/release-notes/3.0/#increased-number-of-replica-set-members>
   . 


There are many advantages to running the Config Servers as a replica set 
(and thus on separate machines), namely: better fault tolerance and 
improved consistency. 


Please see Replica Set Config Servers 
<https://docs.mongodb.com/v3.2/core/sharded-cluster-config-servers/#replica-set-config-servers>
 for more information regarding this subject.


In a pre-CSRS implementation, if any config server goes down, no cluster 
operation that modifies the metadata can take place (e.g. balancing, chunk 
splitting). This is detailed in the documentation for Sharded Cluster, HA 
<https://docs.mongodb.com/v3.0/core/sharded-cluster-high-availability/#one-or-two-config-servers-become-unavailable>
.


Regards,




Chris




On Wednesday, May 4, 2016 at 5:58:17 AM UTC+10, Flash Gorman wrote:

Suppose I have three shards and each shard is a replica set consisting of 
three *mongod* instances.  Suppose furthermore that I run each instance 
on its own machine - so I have a total of *six servers*:

   - Shard 1
   - mongod-1
      - mongod-2
      - mongod-3
   - Shard 2
      - mongod-4
      - mongod-5
      - mongod-6
   
I know I need to have at least *three* *config servers* but it is not 
clear to me where they should run.  Should I run the three config servers 
on the three servers I am using for Shard 1?  Or split them across the two 
shards (run one or two of them on Shard 1 servers and run one or two of 
them on Shard 2 servers)?  Or should I have another dedicated set of 
machines just for the config servers?


-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/5e0ccfab-a248-4584-b746-5d1e39795adc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?