How to set up a MongoDB Sharded Cluster 10 comments


MongoDB Sharded ClusterDefinition

A sharded cluster is a set of Replica Sets (shards) whose mission is to distribute the load uniformly, so that we can scale horizontally our applications in order to work with huge amounts of data.

Advantages of a sharded cluster

The main features of a sharded cluster are:

  • Scalability: From a standalone server to distributed architectures of huge clusters (This allows us to shard our database transparently across all our shards. This increases the performance of our data processing).
  • Load balancing: Automatic data movement across different shards for load balancing. The balancer decides when to migrate the data and the destination Shard, so they are evenly distributed among all servers in the cluster. Each shard stores the data for a selected range of our collection according to a partition key.

Our sharded cluster configuration

This is the configuration we will use in our sharded cluster:

  • Three config servers (the minimum in a production environment): the mongos will query them to know the shard to which enroute the clients requires. We will allocate them in the juan-mongodbspain machine.
  • Two Replica Sets (a and b), each one with three nodes (enough to show how to set up the cluster). Each Replica Set in a separate machine, the first in juan-mongodbspain and the second one in juan-mongodbspain2.
  • Two mongos (they request the information needed by the clients to the shard that contains it). Both of them will be allocated in the juan-mongodbspain machine.

Creating directories

We can not start the services if we have not created the directories in which we will store our data. We will use these ones:

  • cfg0, cfg1 and cfg2 for the three config server
  • a0, a1 and a2 for the nodes of the Replica Set called ‘a’
  • b0, b1 and b2 for the nodes of the Replica Set called ‘b’

Order

We will follow this order to start the instances of our sharded cluster:

  1. Config servers
  2. mongod’s
  3. mongo’s

Config servers

These are the commands we will use for the config servers:

With the ‘configsvr’ option we indicate that the service will be a config service.

As we can see, we allocate the three config servers in the juan-mongodbspain machine, for that reason we use different ports. With different machines we should not specify any ports.

mongod’s

In the last post we talked about how to set up a Replica Set, you can read it here:

Now it is the turn of the six nodes of the two Replica Sets. The first three nodes belong to the first Replica Set (shard) and they will be in one machine. The other three belong to the second shard and they will be in the other machine.

In the command we must specify that our mongod will belong to a sharded cluster. For this purpose we use the ‘–shardsvr’ option. 27018 is the default port for these instances.

Now the second shard, remember that it is in the other machine:

mongo’s

Except for administrative tasks, we will never connect ourselves to a mongod, neither to a config server. The apps will connect to the mongos which mission is to send the queries to the appropiate shards. For this reason we specify ports different to the standard in all of our instances. Therefore, our apps will only be able to connect to the database through a mongos.

This is the command:

As we can see, the first command does not specify any port. Hence, this mongos will listen at the port by default (27017).

Checking our services

Now we will check that all of our services are running:

In the other machine we have the mongod’s corresponding to the second shard:

Replica Set configurations

Now we must configure our Replica Sets (we have explained it in an earlier post). I show it only for the first Replica Set because it is identical in both of them.

Cluster configuration

The last thing we must do is to add our shards to the cluster. We will do it from the first mongos, but before doing it we can check that our cluster has not any shard yet.

Ok, let’s add our two shards to the cluster:

Now, our cluster is conformed by the two shards:

Cluster Balancer

So we can know if the balancer is active:

We have finished the setup of the sharded cluster. In a future post we will explain how to shard a collection.

In the next post we will talk about how to upgrade a stand-alone node, a Replica Set and a Sharded Cluster.


Leave a comment

Your email address will not be published. Required fields are marked *

5 + four =

10 thoughts on “How to set up a MongoDB Sharded Cluster

  • Javier

    Hola Juan,

    soy nuevo en el uso de mongoDB y estoy intentando comprender todo tu artículo (muy interesante por cierto), y tengo algunas dudas..a ver si me puedes echar un cable..

    1) Cuando te refieres a mongos, los dos en concreto que pones en el esquema del cluster, a qué te refieres exactamente?

    2) Veo que los tres servidores de configuración y los dos mongos van en la misma máquina. Qué pasaría si se cayera esa máquina? Cómo reaccionaría el cluster?

    Tengo muchísimas dudas y me gustaría saber si podemos hablar de manera más continuada. no te quitaré mucho tiempo.

    gracias y saludos!

    Javier Martínez Sáez

    • juan Post author

      Hola Javier!

      Cuando hablo de mongos me estoy refiriendo a los routers. Siempre que tenemos un cluster debemos conectar nuestros clientes a MongoDB a través de ellos y, nunca directamente a los nodos de las replicas.

      El mongos, gracias a los config servers, sabrá a qué shard debe enrutar las peticiones de los clientes, de tal forma que la configuración del cluster es transparente para ellos.

      Con respecto a tu segunda pregunta, la configuración aquí mostrada no es óptima para utilizar en un entorno de producción por el motivo que expones. Sólo intenta comprender cómo configurar el sharded cluster y las posibilidades que MongoDB te permite.

      Estoy a tu disposición para todo lo que necesites.
      Un saludo

  • Betsabe

    Hola que tal,muy buen aporte! .

    Tengo algunas dudas respecto a la configuración del cluster, tal vez me puedas ayudar a comprender mejor esto.
    1)Es posible que el cluster funcione con 2 configsvr en producción?
    2) Los configsvr deben estar en maquinas diferentes?
    3) El Cluster solo funciona con replicas? o es posible su configuración sin ellas?

    De ante mano gracias y quedo a la espera de sus aclaraciones u observaciones.
    Saludos.

    • juan Post author

      Buenos días Betsabe

      Contesto tus preguntas por orden:

      1) Es posible que el cluster funcione con 2 configsvr en producción?

      Sí es posible, podría funcionar incluso con un único config server. Imagina el caso de un cluster activo y en el que necesitamos realizar alguna labor de administración en los configsvr, como podría ser un upgrade. Mientras dura esa operación el cluster funcionaría con un configsvr menos sin problema.

      A pesar de ser posible no es recomendable, ¿por qué? Para garantizar la alta disponibilidad de sus datos. Igual que la configuración mínima recomendada de una Replica Set es de tres nodos.

      2) Los configsvr deben estar en maquinas diferentes?

      Únicamente por razones de seguridad. MongoDB es totalmente flexible en este sentido. Incluso podrías montar un cluster completo en una única máquina pero, ¿es lógico?, ¿qué pasaría si se cae esa máquina? te quedarías sin servicio ¿verdad? Con los config servers nos pasa igual, si configuramos los tres en una misma máquina y esta se cae…

      Siempre has de buscar la mejor configuración posible en función de las máquinas de las que dispongas.

      3) El Cluster solo funciona con replicas? o es posible su configuración sin ellas?

      El hecho de tener réplicas nos garantiza la alta disponibilidad de los datos. En caso de no preocuparnos esto no es necesario tener réplicas. Por lo tanto, es perfectamente posible un cluster sin réplicas.

      En un Replica Set el único nodo que soporta las escrituras y lecturas (por defecto) es el primario, los secundarios, en principio, sólo sirven para recibir la réplica de los datos.

      El cluster distribuye la carga de trabajo entre los primarios de sus réplicas de manera uniforme. No necesita la existencia de esos secundarios para su correcto funcionamiento.

      Espero haberte servido de ayuda.

      Un saludo

  • Mark

    Tengo una pregunta tengo actualmente un mongodb y quisiera aligerar la carga de esta a través de Sharded Cluster ya que va empezar a tener mayor carga. Había pensando en agregar 2 servidores mas de mongodb pero por lo que leo necesito 6 mas (uno para cada config de cada maquina y otro para el router), imagino que estas maquinas son mas ligeras en cuanto a hardware cuanto seria lo recomendado?

    A decir verdad me gustaría no crear tantos servidores por lo que me planteo que cada router y config vaya en la misma maquina que va fragmentar (osea que tendría 3 servicios relacionados con mongo, cada servidor de mongo correria config, router y shared), seria valida esta arquitectura?

    Evidentemente ya tengo datos en el primer servidor de mongo, puedo correr riesgo ?

    • juan Post author

      Hola Mark, ¡gracias por escribir!

      Los requerimientos de hardware necesarios para las máquinas que van a correr los servicios de config server son menores que los de aquellas máquinas que van a guardar los datos, los mongod. Es muy dificil darte un consejo sin conocer exáctamente tu aplicación, su modelo de datos, volumen de datos, expectativas de crecimiento, tasas de lectura y escritura, etc.

      Lo que sí te puedo decir es que no hay ningún problema “técnico” en que utilices una máquina para correr los mongod, los mongos o, incluso, los config server. Lógicamente, lo ideal sería tener cada uno de ellos en una máquina distinta. Yo crearía los tres config servers desde el principio. En cuanto a los mongos (routers), no es necesario tener uno por cada shard, dependiendo del tráfico que tengas podrás más adelante añadir.

      ¿Te has planteado implementar una Replica Set en cada shard? Puedes ver cómo hacerlo en este otro artículo How to set up a MongoDB Replica Set

      Espero haberte servido de ayuda,
      Juan

      • Mark

        Hola Juan muchas gracias por responder.

        Me ha servido de mucho tu respuesta, voy hacer todo lo posible por separar 3 shared, los 3 config servers y agregar 2(3) mongos (routers), voy a utilizar maquinas mas ligeras para el config y el router (si es posible virtualizadas 1GB de Ram, 1 core y 20GB de HDD), te cuento como me fue.

        Me encantaría poder aplicar Replica Set en cada shared, pero no tenemos tanto presupuesto para cada uno 🙁

        • juan Post author

          Mark, no hay ningún problema por tener datos en tu servidor actual. Una vez añadas el resto de shards, habilites el particionado en tu base de datos y particiones tu/tus colección/colecciones el balanceador comenzará a distribuir tus datos entre tus shards para que todos tengan la misma carga de trabajo. Si no lo haces así, tu aplicación seguirá utilizando únicamente el servidor donde reside tu base de datos actual y estarás desaprovechando los nuevos.

          Para el particionado de la/las colección/colecciones es muy importante escoger bien la shardkey.

          Por favor, cuéntame cómo te ha ido cuando lo tengas en marcha.

          Un saludo,
          Juan

  • orwell

    Buen post!, pero tengo una consulta al agregar un replicaset que se encuentra ubicado en otro servidor: sh.addShard(“b/mongo02:27000”), me sale el siguiente error:

    “errmsg” : “could not find host matching read preference { mode: \”primary\” } for set b”,

    He revisado, pero no encuentro que podria estar mal, si puedes ayudarme, te lo agracederia.

    Saludos

    • juanroy Post author

      Hola Orwell, ¡muchas gracias por animarte a participar en mi blog!

      Lo que está ocurriendo es que no tienes dados de alta en el fichero /etc/hosts, de una o ambas máquinas, los hostnames que estás utilizando.

      Gracias de nuevo y un saludo.