MongoDB mongos las instancias enrutan las queries y operaciones de escritura a particiones en un clúster. mongos proporciona la única interfaz a un clúster fragmentado desde la perspectiva de las aplicaciones. Las aplicaciones nunca se conectan ni se comunican directamente con las particiones.
El mongos realiza un seguimiento de qué datos están en qué partición almacenando en caché los metadatos de los servidores de configuración. El mongos utiliza los metadatos para dirigir las operaciones de las aplicaciones y los clientes a las instancias de mongod. Un mongos no tiene un estado persistente y consume pocos recursos del sistema.
La práctica más común es ejecutar instancias de mongos en los mismos sistemas que tus servidores de aplicaciones, pero puedes mantener instancias de mongos en las particiones o en otros recursos dedicados. Ver también Cantidad de mongos y Distribución.
Proceso de encaminamiento y resultados
Una mongos instancia enruta una query a un clúster al:
Determinando la lista de particiones que deben recibir la query.
Establecer un cursor en todos los fragmentos seleccionados.
Luego, mongos fusiona los datos de cada uno de los fragmentos de destino y devuelve el documento resultante. Ciertos modificadores de consulta, como la ordenación, se realizan en cada partición antes de que mongos recupere los resultados.
Las operaciones de agregación que se ejecutan en múltiples particiones pueden encaminar los resultados de vuelta al mongos para combinar los resultados si no necesitan ejecutarse en la partición principalde la base de datos.
Hay dos casos en los que un pipeline no es apto para ejecutarse en mongos.
El primer caso ocurre cuando la parte de fusión del pipeline dividido contiene una etapa que debe ejecutarse en una partición específico. Por ejemplo, si $lookup necesita acceder a una colección no particionada en la misma base de datos que la colección particionada en la que se está ejecutando la agregación, la fusión se realiza en la partición que aloja la colección no particionada.
El segundo caso ocurre cuando la parte de fusión de la canalización dividida contiene una etapa que puede escribir datos temporales en el disco, como $group, y el cliente ha especificado allowDiskUse:true. En este caso, suponiendo que no hay otras etapas en la canalización de fusión que requieran el fragmento principal, la fusión se ejecuta en un fragmento seleccionado aleatoriamente del conjunto de fragmentos objetivo de la agregación.
Para obtener más información sobre cómo se reparte el trabajo de agregación entre los componentes de una query en clúster, usa explain:true como parámetro en la llamada aggregate(). El retorno incluye tres objetos JSON:
mergeTypemuestra dónde ocurre la etapa de la fusión ("anyShard", "specificShard" o "router"). CuandomergeTypeesspecificShard, el output agregado incluye una propiedadmergeShardque contiene el ID de la partición de la partición que se está fusionando.splitPipelineMuestra qué operaciones de su canalización se han ejecutado en fragmentos individuales.shardsMuestra el trabajo que ha realizado cada fragmento.
En algunos casos, cuando la clave de fragmento o un prefijo de la clave de fragmento es parte de la consulta,mongos realiza una operación específica y enruta las consultas a un subconjunto de fragmentos en el clúster.
mongos realiza una operación de difusión para consultas que no incluyen la clave de partición, dirigiendo las consultas a todas las particiones del clúster. Algunas queries que incluyen la clave de partición aún pueden dar lugar a una operación de difusión en función de la distribución de datos en el clúster y la selectividad de la query.
Consulte Operaciones dirigidas vs. Operaciones de transmisión para obtener más información sobre operaciones dirigidas y de transmisión.
Cómo mongos maneja los modificadores de consulta
Clasificación
Si el resultado de la query no está ordenado, la instancia mongos abre un cursor de resultados que "distribuye en rondas" los resultados de todos los cursores en las particiones.
Límites
Si la query limita el tamaño del conjunto de resultados utilizando el método de cursor limit(), la instancia mongos pasa ese límite a las particiones y luego vuelve a aplicar el límite al resultado antes de devolver el resultado al cliente.
Saltos
Si la query especifica el número de registros a omitir utilizando el método de cursor skip(), el mongos no puede pasar el omitir a las particiones, sino que recupera los resultados no omitidos de las particiones y omite el número apropiado de documentos al ensamblar el resultado completo.
Cuando se usa junto con limit() un, el mongos pasa el límite más el valor de a los fragmentos para mejorar la eficiencia de estas skip() operaciones.
Preferencia de lectura y Particiones
Para clústeres fragmentados, mongos aplica la preferencia de lectura a la hora de leer de las particiones. El nodo seleccionado está gobernado tanto por la configuración de la preferencia de lectura como por la configuración de replication.localPingThresholdMs, y se volverá a evaluar para cada operación.
Para obtener detalles sobre las preferencias de lectura y los clústeres fragmentados, consulte Preferencias de lectura y fragmentos.
Confirmar la conexión a mongos instancias
Para detectar si la instancia de MongoDB a la que está conectado su cliente esmongos, use el comandohello. Cuando un cliente se conecta a una instanciamongos, hellodevuelve un documento con un campo msg que contiene la cadena isdbgrid. Por ejemplo:
{ "isWritablePrimary" : true, "msg" : "isdbgrid", "maxBsonObjectSize" : 16777216, "ok" : 1, ... }
Si la aplicación, en cambio, está conectada a un mongod, el documento retornado no incluye la string isdbgrid.
Operaciones específicas frente a operaciones de difusión
Generalmente, las consultas más rápidas en un entorno particionado son aquellas que mongos se redirigen a una sola partición, usando la clave de partición y la metainformación del clúster del servidor de configuración. Estas operaciones específicas utilizan el valor de la clave de partición para localizar la partición o subconjunto de particiones que satisfacen el documento de query.
Para las consultas que no incluyen la clave de partición, mongos debe consultar todas las particiones, esperar sus respuestas y luego devolver el resultado a la aplicación. Estas consultas de "dispersión/recopilación" pueden ser operaciones de larga duración.
Operaciones de transmisión
mongos Las instancias transmiten queries a todas las particiones de la colección a menos que el mongos pueda determinar qué partición o subconjunto de particiones almacena estos datos.
Después de que el mongos reciba respuestas de todas las particiones, fusiona los datos y devuelve el documento de resultados. El rendimiento de una operación de difusión depende de la carga global del clúster, así como de variables como la latencia de la red, la carga individual de las particiones y la cantidad de documentos devueltos por partición. Siempre que sea posible, favorece las operaciones que resulten en una operación dirigida sobre aquellas que resulten en una operación de transmisión.
Las operaciones de actualización múltiple siempre son operaciones broadcast.
Los métodos updateMany() y deleteMany() son operaciones difusas, a menos que el documento de query especifique la clave de partición completa.
Operaciones específicas
mongos puede enrutar queries que incluyan la clave de partición o el prefijo de una clave compuesta a una partición específica o a un conjunto de particiones. mongos utiliza el valor de la clave de partición para ubicar al fragmento cuyo rango incluye el valor de la clave de partición y dirige la consulta a la partición que contiene ese fragmento.
Por ejemplo, si la clave de partición es:
{ a: 1, b: 1, c: 1 }
El programa mongos puede enrutar queries que incluyan la clave completa de partición o cualquiera de los siguientes prefijos de clave de partición a una partición específica o a un conjunto de particiones:
{ a: 1 } { a: 1, b: 1 }
Todas las operaciones se dirigen a insertOne() insertMany() un fragmento. Cada documento de la matriz se dirige a un único fragmento, pero no hay garantía de que todos los documentos de la matriz se inserten en un único fragmento.
Todas las updateOne() replaceOne() operaciones,deleteOne() y deben incluir la clave de fragmento o _id en el documento de consulta. MongoDB devuelve un error si estos métodos se utilizan sin la clave de fragmento _id o.
Dependiendo de la distribución de los datos en el clúster y de la selectividad de la query, mongos aún puede realizar una operación de transmisión para cumplir con estas queries.
Uso del índice
Cuando una partición recibe una query, utiliza el índice más eficiente disponible para cumplir con esa query. El índice utilizado puede ser tanto el índice de clave de partición como otro índice elegible presente en la partición.
Seguridad en el clúster particionado
Utiliza la autenticación interna/de membresía autogestionada para aplicar la seguridad entre clústeres y evitar que componentes del clúster no autorizados accedan al clúster. Debes iniciar cada mongod o mongos en el clúster con la configuración de seguridad adecuada para aplicar la autenticación interna.
A partir de MongoDB 5.3, SCRAM-SHA-1 no se puede usar para la autenticación intraclúster. Solo se admite SCRAM-SHA-256.
En versiones anteriores de MongoDB, se pueden usar tanto SCRAM-SHA-1 como SCRAM-SHA-256 para la autenticación intra-clúster, incluso si SCRAM no está explícitamente habilitado.
Consulta Implementar clúster fragmentado autogestionado con autenticación de clave para aprender cómo implementar un clúster fragmentado seguro.
Usuarios del clúster
Los clústeres fragmentados admiten Control de Acceso Basado en roles en implementaciones autogestionados (RBAC) para restringir el acceso no autorizado a los datos y operaciones del clúster. Debe iniciar cada mongod en el clúster, incluidos los servidores de configuración, con la opción --auth para aplicar RBAC. Como alternativa, el aplicar la Autenticación interna/de membresía autogestionada para la seguridad entre clústeres también habilita controles de acceso de usuario a través de RBAC.
Con RBAC implementado, los clientes deben especificar,--username --passwordy --authenticationDatabase al conectarse mongos al para poder acceder a los recursos del clúster.
Cada clúster tiene sus propios usuarios. Estos usuarios no pueden usarse para acceder a fragmentos individuales.
Consulta Activar el control de acceso en implementaciones autogestionadas para ver un tutorial sobre cómo añadir usuarios a una implementación de MongoDB con RBAC habilitado.
Operaciones de metadatos
mongos usa preocupación de escritura para las siguientes operaciones que afectan los metadatos del clúster "majority" fragmentado:
Información Adicional
Compatibilidad de características entre versiones
El binario mongos no puede conectarse a mongod instancias cuya compatibilidad de características entre versiones (FCV) sea superior a la del mongos. Por ejemplo, no puedes conectar un MongoDB 4.0 versión mongos a un 4.2 clúster particionado con compatibilidad de características entre versiones establecido en 4.2. Sin embargo, puedes conectar un MongoDB 4.0 versión mongos a un 4.2 clúster fragmentado con compatibilidad de características entre versiones establecido en 4.0.
Requisitos de captura de datos de diagnóstico a tiempo completo
mongod incluye un mecanismo de Full Time Diagnostic Data Capture para asistir a los ingenieros de MongoDB con la solución de problemas en las implementaciones. Si este hilo falla, termina el proceso que lo originó. Para evitar los errores más comunes, confirme que el usuario que ejecuta el proceso tenga permisos para crear el directorio FTDC diagnostic.data. Para mongod, el directorio se encuentra dentro de storage.dbPath. Para mongos, es paralelo a systemLog.path.
Pools de conexiones
A partir de MongoDB 4.2, MongoDB añade el parámetro ShardingTaskExecutorPoolReplicaSetMatching. Este parámetro determina el tamaño mínimo del mongod / mongos pool de conexiones de cada instancia para cada nodo del clúster. Este valor puede variar durante el tiempo de ejecución.
mongod y mongos mantienen pools de conexión a cada uno de los secundarios del set de réplicas para cada set de réplicas en el clúster. Por defecto, estos pools tienen un número de conexiones que es al menos igual al número de conexiones al primario.
Para modificar, consulte ShardingTaskExecutorPoolReplicaSetMatching.
Uso de pipelines de agregación con clústeres
Para obtener más información sobre cómo funciona la fragmentación con agregaciones, lea el capítulo sobre fragmentación en Agregaciones prácticas de MongoDB. libro electrónico.