You have linked the relevant official request for this in your answer and SERVER-3748 does explain some of the reasons why these don't currently exist.
The most basic reason is that you cannot start mongos
without at least one config server being up and working, otherwise it will refuse to start, which makes it a poor candidate for an init script (external dependencies). Generally you want to avoid having services that are going to fail to start when there is no good way to check the reason for failure.
However, it would still be beneficial to give people a script rather than having them modify/write one themselves, hence the Jira issue exists.
The way I would recommend to do this is to base any script off of the existing mongod
init script and simply modify it to replace mongod
with mongos
where appropriate. Here is the current version of that script for Debian:
https://github.com/mongodb/mongo/blob/master/debian/init.d
Things you will need to change:
> DAEMON=/usr/bin/mongos
> DESC=mongos-router
>
> NAME=mongos
>
> CONF=/etc/mongos.conf
> PIDFILE=/var/run/$NAME.pid
> ENABLE_MONGODB=yes
The advantage to doing this, after you have installed the 10gen package, is that the users will already be set up and you have the mongod
script for reference on the system.
You will need to create the config file with appropriate values for your mongos, and there might be a couple of other things you need to tweak - the key is to test before you make anything permanent.
Once you confirm via testing that you have the script working as you wish, then you can add it permanently with update-rc.d
Best Answer
The term "server" is unfortunately overloaded in this context: it may refer to either the config server daemon process or a physical/virtual server.
For a production sharded cluster running MongoDB 2.4, you should definitely have three config server processes (i.e.
mongod --configsvr
). There is no strict requirement for these processes to be separately hosted, so you can potentially colocate config servermongod
processes within your existing server environments to save on hosting costs.Config servers are generally reasonably lightweight in terms of storage and CPU/memory usage, as the metadata for a sharded cluster is significantly smaller than the actual cluster data. If you do choose to colocate the config servers,
mongos
will be a much better neighbour than data-bearingmongod
shard servers.Some key considerations when colocating sharded cluster components include:
Resilience: a single server/instance failure can now cause multiple components to be unavailable.
Resource usage: multiple components will be competing for the same resources (RAM, CPU, I/O, ...).
Future scaling: you should use CNAMEs for the config servers to allow them to potentially be moved to separate hosts in future without downtime.
You will also find that the first config server listed in your
mongos
--configdb
string will receive a larger percentage of network traffic than the other two config servers. This may influence whether you colocate the first config server with your web node or a processing node; you probably want to choose whichever currently has more available network bandwidth.