MongoDB Sharding, Replication and Clusters

MongoDB MongoDB es la base de datos de la siguiente generación que te permite hacer cosas que nunca antes podías hacer. Es un sistema líder de administración de bases de datos non-relational y un miembro prominente del movimiento NoSQL. En lugar de utilizar las tablas y los esquemas fijos de relational database management system (RDBMS), MongoDB utiliza el almacenamiento de valores clave en la colección de documentos.

También es compatible con varias opciones de escalado horizontal en entornos de producción grandes. MongoDB es un sistema de base de datos de documentos NoSQL que se escala horizontalmente e implementa el almacenamiento de datos a través de un sistema de clave-valor. Aprender MongoDB Sharding, Replication y Clusters es muy importante ya que es una opción popular para aplicaciones y sitios web hoy día. MongoDB es fácil de implementar y acceder mediante programación.

¿Qué es MongoDB Sharding?

MongoDB logra escalar a través de una técnica conocida como “sharding”. Es el proceso de escritura de datos en diferentes servidores para distribuir los requisitos de carga de lectura y escritura y almacenamiento de datos. Sharding es el proceso de almacenar registros de datos en varias máquinas y es el enfoque de MongoDB para satisfacer las demandas de crecimiento de datos. A medida que aumenta el tamaño de los datos, una sola máquina no puede ser suficiente para almacenar datos ni proporcionar un rendimiento aceptable de lectura y escritura. Sharding resuelve el problema con la escala horizontal. Con Sharding, usted agrega más máquinas para admitir el crecimiento de datos y las demandas de las operaciones de lectura y escritura.

¿Qué es MongoDB Replication?

A diferencia de los servidores de base de datos relacionales, escalar la base de datos NoSQL para satisfacer la mayor demanda en su aplicación es bastante simple: inserte un nuevo servidor, haga un par de cambios de configuración y conéctese a sus servidores existentes, ampliando el clúster. Todas las base de datos y colecciones existentes se replican automáticamente y se sincronizan con los otros nodos miembros. Un clúster de replicación funciona bien cuando todo el volumen de datos de su base de datos puede caber en un único servidor. Cada servidor en su clúster de replicación alojará una copia completa de su base de datos. Los Conjuntos de réplicas son una excelente forma de replicar los datos de MongoDB en varios servidores y hacen que la base de datos falle automáticamente por error en caso de falla del servidor. Las cargas de trabajo de lectura se pueden escalar haciendo que los clientes se conecten directamente a las instancias secundarias. Tenga en cuenta que la replicación MongoDB maestro/esclavo no es lo mismo a un conjunto de réplicas, y no tiene falla automático.

Clústeres de MongoDB:

MongoDB Cluster contiene tres componentes separados

1. Servidor de configuración (mongod) Los servidores de configuración se utilizan para almacenar los metadatos que vinculan los datos solicitados con el shard que lo contiene. Organiza los datos para que la información pueda recuperarse de manera confiable y consistente. Usamos solo un servidor de configuración para fines de prueba.

2. Enrutadores de consultas (mongos) Estas máquinas son responsables de comunicarse con los servidores de configuración para averiguar dónde se almacenan los datos solicitados. Luego, accede y devuelve los datos de los shards apropiados. Cada enrutador de consulta ejecuta el comando “mongos”.

3. Servidors Shard (mongod) Los shards son responsables de las operaciones de almacenamiento de datos reales. En entornos de producción, un único shard generalmente se compone de un conjunto de réplicas en lugar de una sola máquina. Esto es para garantizar que los datos seguirán estando accesibles en caso de que un servidor de shard primario se desconecte.En MongoDB Cluster, los datos se dividen en estos shards por igual (según la configuración del equilibrador)

4. Réplicas y Conjunto de réplicas MongoDB maneja la replicación a través de una implementación llamada “conjunto de réplicas”. Los conjuntos de réplica en su forma básica son algo similares a los nodos en una configuración maestro-esclavo. Un único miembro primario se usa como base para aplicar cambios a los miembros secundarios.

CLUSTER

|–> Config Servers |–> Query Routers |–> Shard Servers (Replica Set)

|–> Replicas

¿Cómo configurar un Cluster de Sharded para conjuntos de datos distribuidos de alta disponibilidad?

Inicializar servidores de configuración y configurar el enrutador de consultas Puede inicializar el servidor de configuración configurando su función como configsvr y configdb respectivamente. Puede iniciar el servidor mongod y mongos simplemente agregando -configsvr y -configdb en el comando.

Inicie la réplica y agregue miembros Desde el shell de mongo, inicie el conjunto de réplicas:

rs.initiate()

Este comando inicia una réplica establecida con el host actual como su único miembro. Esto es confirmado por la salida, que debería parecerse a lo siguiente:

{ “info2” : “no configuration specified. Using a default configuration for the set”, “me” : “192.0.2.1:27017”, “ok” : 1 }

Mientras esté conectado al shell mongo, agregue los otros hosts al conjunto de réplicas:

rs.add("mongo-repl-2")
rs.add("mongo-repl-3")

Si configuró otros miembros para su conjunto de réplicas, agréguelos usando el mismo comando y los nombres de host que configuró en su archivo /etc/hosts. Una vez que se hayan agregado todos los miembros, verifique la configuración de su conjunto de réplicas:

rs.conf()

Esto mostrará un objeto de configuración del conjunto de réplicas con información sobre cada miembro, así como algunos metadatos sobre el conjunto de réplicas. Si necesita hacerlo en el futuro, también puede verificar el estado de su conjunto de réplicas:

rs.status()

Esto muestra el estado, el tiempo de actividad y otros datos sobre el conjunto. Si su conjunto de réplicas está configurado correctamente, los datos deben estar presentes en sus miembros secundarios así como también en el primario. Para probar esto, conéctese al shell mongo con el usuario administrativo en uno de sus miembros secundarios y ejecute:

db.getMongo().setSlaveOk()

Este comando permite las operaciones de lectura de miembros secundarios en base de cada conexión, así que asegúrese de desconectarse antes de implementar su réplica en producción. De forma predeterminada, las consultas de lectura no están permitidas en miembros secundarios para evitar problemas con la recuperación de datos obsoletos de la aplicación. Esto puede convertirse en un problema cuando su base de datos se somete a consultas más complejas a una carga mayor, pero debido a los datos de prueba relativamente simples que escribimos, esto no es un problema aquí.

Agregar Shards al clúster Desde la interfaz de mongos, agregue cada shard individualmente:

sh.addShard( "mongo-shard-1:27017" )
sh.addShard( "mongo-shard-2:27017" )

Todos estos pasos se pueden hacer desde una sola conexión de mongos; no necesita iniciar sesión en cada shard individualmente y hacer la conexión para agregar un nuevo shard. Si está utilizando más de dos shards, puede usar este formato para agregar más shards también. Asegúrese de modificar los nombres de host en el comando anterior si corresponde. Opcionalmente, si configuró conjuntos de réplica para cada shard en lugar de servidores únicos, puede agregarlos en esta etapa con un comando similar:

sh.addShard( "rs0/mongo-repl-1:27017,mongo-repl-2:27017,mongo-repl-3:27017" )

En este formato, rs0 es el nombre de la réplica establecida para el primer shard, mongo-repl-1 es el nombre del primer host en el shard (utilizando el puerto 27017), y así sucesivamente. Tendrá que ejecutar el comando anterior por separado para cada conjunto de réplicas individuales.

Habilitar Sharding a nivel de base de datos Habilite el sharding en la nueva base de datos:

sh.enableSharding("exampleDB")

Estrategia de Sharding Antes de habilitar sharding para una colección, tendremos que decidir sobre una estrategia de sharding. Cuando los datos se distribuyen entre los shards, MongoDB necesita una forma de ordenarlos y saber qué datos están en qué shard. Para hacer esto, utilice una clave de shard, un campo designado en sus documentos que es utilizado por el enrutador de consultas de mongos que sabe dónde se almacena una determinada pieza de datos. Las dos estrategias de sharding más comunes son basadas en rango y basadas en hash.

• Sharding basado en rangos
• Sharding basado en hash

Habilitar Sharding en el nivel de recopilación Crea una nueva colección llamada exampleCollection y hash its _id clave. La clave _id ya está creada de manera predeterminada como un índice básico para nuevos documentos:

db.exampleCollection.ensureIndex( { _id : "hashed" } )

Finalmente, shard la colección:

sh.shardCollection( "exampleDB.exampleCollection", { "_id" : "hashed" } )

Pon a prueba tu clúster Verifica tu distribución de datos:

db.exampleCollection.getShardDistribution()

También puede obtener más información sobre los documentos oficiales de MongoDB. En Tudip, hemos configurado todos los scripts para realizar MongoDB Sharding, Replication, Clusters y varias operaciones.