Docs Menu
Docs Home
/ /

Preguntas frecuentes: Particionado con MongoDB

Este documento responde preguntas comunes sobre Fragmentación. Consulte también la sección Fragmentación del manual, que ofrece una descripción general de la fragmentación, incluyendo detalles sobre:

A veces. Sin embargo, si su conjunto de datos cabe en un solo servidor, debería comenzar con una implementación sin fragmentación, ya que fragmentar cuando su conjunto de datos es pequeño ofrece pocas ventajas.

Las opciones para cambiar una clave de partición dependen de la versión de MongoDB que está ejecutando:

Tip

El balanceador comienza a distribuir datos entre los fragmentos una vez que la distribución de fragmentos alcanza ciertos umbrales. Consulte Umbrales de migración.

Además, MongoDB no puede mover un fragmento si el número de documentos que contiene supera un determinado número. Consulte Número máximo de documentos por rango para migrar y Fragmentos indivisibles/jumbo.

mongosLas instancias mantienen un caché de la base de datos de configuración que contiene los metadatos del clúster fragmentado.

mongos actualiza su caché de forma diferida al enviar una solicitud a un fragmento y descubrir que sus metadatos están desactualizados. Para forzar a a recargar su mongos flushRouterConfig caché, mongos puede ejecutar el comando directamente contra cada.

El receptor de reescritura es un proceso que inicia un sondeo largo para retransmitir las reescrituras de un mongod o mongos un después de las migraciones, a fin de garantizar que no se hayan dirigido al servidor incorrecto. El receptor de reescritura envía las reescrituras al servidor correcto si es necesario.

Estos mensajes son una parte clave de la infraestructura de fragmentación y no deberían causar preocupación.

Cada instancia mantiene un conjunto de conexiones con los miembros del clúster fragmentado. Las solicitudes de cliente utilizan estas conexiones una a una; es decir, no se multiplexan ni mongos canalizan.

Cuando se completan las solicitudes de cliente, el mongos devuelve la conexión al pool. Estos pools no se reducen al disminuir el número de clientes. Esto puede generar un mongos sin usar con una gran cantidad de conexiones abiertas. Si el mongos ya no se usa, es seguro reiniciar el proceso para cerrar las conexiones existentes.

Para devolver estadísticas agregadas relacionadas con todos los grupos de conexiones salientes utilizados por,mongos conecte mongosh al y mongos connPoolStats ejecute el comando:

db.adminCommand("connPoolStats");

Consulte la sección Utilización de recursos del sistema del documento Configuración de UNIX ulimit para implementaciones autoadministradas.

Volver

Simultaneidad

En esta página