Preguntas frecuentes

¿Por qué recibo errores al conectar a MongoDB?

Si tienes problemas para conectar con una implementación de MongoDB, consulta la Guía de solución de problemas de conexión para soluciones posibles.

¿Cómo funciona el agrupamiento de conexiones en el controlador .NET/C#?

Cada MongoClient La instancia tiene un pool de conexiones integrado para cada servidor en su topología de MongoDB. Los pools de conexiones abren sockets on-demand para soportar operaciones concurrentes de MongoDB en su aplicación multihilo.

El tamaño máximo de cada pool de conexiones se configura mediante la opción MaxConnectionPoolSize, cuyo valor por defecto es 100. Si el número de conexiones en uso a un servidor alcanza el valor de MaxConnectionPoolSize, la siguiente solicitud a ese servidor esperará hasta que una conexión esté disponible. El siguiente diagrama ilustra una visión a alto nivel de cómo MongoClient gestiona un pool de conexiones:

Además de los sockets necesarios para soportar los hilos de tu aplicación, cada instancia de MongoClient abre dos sockets adicionales por servidor en tu topología de MongoDB para la supervisión del estado del servidor. Por ejemplo, un cliente conectado a un set de réplicas de tres nodos abre seis sockets de supervisión. Si la aplicación usa la configuración predeterminada para MaxConnectionPoolSize y solo consulta el nodo principal (predeterminado), entonces puede haber como máximo 106 conexiones en uso. Si la aplicación utiliza una preferencia de lectura para query los nodos secundarios, esos pools de conexiones crecen y puede haber 306 conexiones totales.

Para admitir un gran número de hilos simultáneos de MongoDB dentro de un proceso, puedes aumentar MaxConnectionPoolSize.

El controlador tiene una cola de espera que limita la cantidad de hilos que pueden esperar una conexión. El tamaño de la cola de espera se determina mediante la opción WaitQueueMultiple, que por defecto es 5. Para calcular el tamaño máximo de la cola de espera, el driver multiplica WaitQueueMultiple por MaxConnectionPoolSize. Si utiliza el valor por defecto para cada opción, el tamaño de la cola de espera será de 500. También puedes configurar el tamaño de la cola de espera especificando la opción WaitQueueSize, lo que anula los otros ajustes. Sin embargo, no recomendamos cambiar el tamaño de la cola de espera por defecto.

Los pools de conexiones tienen limitaciones de velocidad. La configuración de MaxConnecting determina el número de conexiones que el pool puede crear en paralelo en cualquier momento. Por ejemplo, si el valor de MaxConnecting es 2, el tercer hilo que intente verificar simultáneamente una conexión solo tendrá éxito en uno de los siguientes casos:

• Uno de los dos primeros hilos termina de crear una conexión.

• Se vuelve a registrar una conexión existente en el pool.

• La capacidad del controlador para reutilizar conexiones existentes mejora debido a los límites de velocidad en la creación de conexiones.

Puedes establecer el número mínimo de conexiones concurrentes a cada servidor utilizando la opción MinConnectionPoolSize, que por defecto es 0. El pool de conexiones se inicializará con este número de sockets. Si los errores provocan el cierre de cualquier socket y el número total de sockets (tanto en uso como inactivos) cae por debajo del mínimo, el driver abre más sockets hasta que el número alcance el mínimo.

Puedes establecer el número máximo de milisegundos que una conexión puede permanecer inactiva en el grupo utilizando la opción MaxConnectionIdleTime. Una vez que una conexión está inactiva durante MaxConnectionIdleTime, el driver la remueve. Esta opción se establece por defecto en 10 minutos. Si el tamaño del pool cae por debajo de MinConnectionPoolSize, el driver remueve y reemplaza la conexión inactiva.

MongoClient también tiene la opción MaxConnectionLifeTime, que especifica la duración de tiempo, 30 minutos por defecto, que una conexión puede mantenerse agrupada antes de expirar.

La siguiente configuración por defecto para un MongoClient funciona para la mayoría de las aplicaciones:

var client = new MongoClient("<connection string>");

Crea un cliente una vez para cada proceso y reutilízalo para todas las operaciones. Es un error común crear un nuevo cliente para cada solicitud, lo que resulta muy ineficiente.

No hay forma compatible de finalizar una MongoClient en el controlador.

¿Por Qué el Controlador Lanza un Tiempo de Espera Durante la Selección del Servidor?

Cada operación del controlador requiere que elijas un servidor saludable que cumpla con los criterios de selección de servidor. Si no selecciona un servidor apropiado dentro del límite de tiempo para selección de servidor, el driver lanza una excepción de límite de tiempo para selección de servidor. La excepción se parece a lo siguiente:

A timeout occurred after 30000ms selecting a server using CompositeServerSelector{ Selectors = MongoDB.Driver.MongoClient+AreSessionsSupportedServerSelector, LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 }, OperationsCountServerSelector }.
Client view of cluster state is
{
    ClusterId : "1",
    Type : "Unknown",
    State : "Disconnected",
    Servers :
    [{
        ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/localhost:27017" }",
        EndPoint: "Unspecified/localhost:27017",
        ReasonChanged: "Heartbeat",
        State: "Disconnected",
        ServerVersion: ,
        TopologyVersion: ,
        Type: "Unknown",
        HeartbeatException: "<exception details>"
    }]
}.

El mensaje de error consta de varias partes:

1. El tiempo de espera de selección del servidor (30000 ms).

2. Los selectores de servidor considerados (CompositeServerSelector que contienen AreSessionsSupportedServerSelector, LatencyLimitingServerSelector, y OperationsCountServerSelector).

3. La vista actual del controlador de la topología del clúster. La lista de servidores de los que el controlador tiene conocimiento es un elemento clave de esta visión. Cada descripción del servidor contiene una descripción exhaustiva de su estado actual, incluida información sobre un endpoint, una versión de servidor, un tipo de servidor y su estado de salud actual. Si el servidor encuentra problemas en el reporte de su estado de salud, HeartbeatException contiene la excepción del último fallo en el latido. Analizar el HeartbeatException en cada nodo del clúster puede ayudar a diagnosticar la mayoría de los problemas de selección de servidores. Las siguientes excepciones del latido del corazón son comunes:

   • No connection could be made because the target machine actively refused it: El controlador no puede ver este nodo de clúster. Esto puede deberse a que el nodo de clúster se haya caído, a que un firewall esté impidiendo el tráfico de red hacia el nodo de clúster o al puerto, o a que otra falla de red esté impidiendo que el tráfico llegue correctamente al nodo de clúster.

   • Attempted to read past the end of the streamEste error ocurre cuando el driver no puede conectarse a los nodos del clúster debido a un error de red, una configuración incorrecta del firewall u otro problema de red. Para resolver esta excepción, asegúrese de que todos los nodos del clúster sean accesibles. Este error ocurre comúnmente cuando la dirección IP de la máquina del cliente no está configurada en la lista de acceso IP de Atlas, que se puede encontrar en la Network Access pestaña para tu Proyecto Atlas.

   • The remote certificate is invalid according to the validation procedureEste error suele indicar un problema relacionado con TLS/SSL, como un certificado expirado/no válido o una CA raíz no confiable. Puedes usar herramientas como openssl s_client para depurar problemas con certificados relacionados con TLS/SSL.

¿Debería usar LINQ, clases Builder o documentos BSON al consultar documentos?

Si estás acostumbrado a programar en C#, considera usar LINQ debido a su similitud con la programación en C# nativo. Si tiene experiencia previa con otros drivers de MongoDB, considere utilizar clase de construcción debido a su coherencia con otros drivers. Los documentos BSON ofrecen la mayor flexibilidad y pueden traducirse más fácilmente a otros lenguajes de programación, pero son menos idiomáticos para C# y no comprueban errores de tipo en tiempo de compilación.

Te animamos a experimentar con cada enfoque para determinar el mecanismo más adecuado para tus fines. Para aprender más sobre la visualización de LINQ y la construcción de query de clase, consulta el MongoDB C# Analyzer. Para obtener ayuda sobre cómo crear consultas de documentos BSON, consulta la documentación de MongoDB Compass.

¿Por qué no se admiten ciertas expresiones LINQ o de desarrolladores?

Cada expresión LINQ o de generador debe estar disponible en la API de query. Esto no siempre es posible por los siguientes motivos:

1. Estás intentando usar una funcionalidad de .NET/C# que no tiene una representación equivalente en MongoDB. Por ejemplo, .NET/C# y MongoDB tienen diferentes semánticas respecto a las intercalaciones.

2. El driver no admite una transformación particular de expresión LINQ o Builder en MQL (Lenguaje de Consulta de MongoDB). Esto puede ocurrir porque la query proporcionada no tiene traducción a MQL o porque una funcionalidad aún no se ha implementado en el driver.

Si recibes un mensaje de excepción Unsupported filter ... o Expression not supported ..., prueba los siguientes pasos:

1. Intenta configurar el nuevo proveedor LINQ3. El proveedor LINQ3 contiene muchas correcciones y nuevas funcionalidades en comparación con el proveedor LINQ2.

2. Utilice el MongoDB C# Analyzer para analizar sus expresiones.

3. Intenta simplificar tu query siempre que sea posible.

4. Proporciona una consulta como una BsonDocument o una cadena JSON. Todas las clases de definición de drivers, como FilterDefinition, ProjectionDefinition y PipelineDefinition, soportan la conversión implícita desde BsonDocument o strings JSON. Por ejemplo, los siguientes filtros son equivalentes cuando se usan en una query o agregación:

FilterDefinition<Entity> typedFilter = Builders<Entity>.Filter.Eq(e => e.A, 1);
FilterDefinition<Entity> bsonFilter = new BsonDocument {{ "a", 1 }};
FilterDefinition<Entity> jsonFilter = "{ a : 1 }";

Puedes combinar las formas en bruto y tipadas en la misma query, como lo demuestra el siguiente código:

FilterDefinition<Entity> filter = Builders<Entity>.Filter
    .And(Builders<Entity>.Filter
        .Eq(e => e.A, 1), BsonDocument
        .Parse("{ b : 2 }"));

¿Qué tipos de objeto Realm se pueden serializar?

El ObjectSerializer permite la serialización y deserialización sólo de los tipos que se consideran seguros. Cuando construyes un ObjectSerializer, puedes pasar un delegado del tipo Func<Type, bool>. Este delegado acepta un tipo de objeto Realm y devuelve un valor booleano que indica si el tipo es seguro para la serialización.

En la mayoría de los casos, debe pasar el delegado ObjectSerializer.DefaultAllowedTypes(). Este método devuelve 'true' para varios tipos de frameworks bien conocidos que hemos considerado seguros. Para serializar tipos personalizados, crea una expresión booleana que se evalúe como true para los tipos que deseas incluir. Luego, añade esta expresión al final del delegado que pasas al constructor ObjectSerializer.

En el siguiente ejemplo, ObjectSerializer serializará y deserializará cualquier tipo permitido por ObjectSerializer.DefaultAllowedTypes() o cuyo nombre completo empiece por "MyNamespace":

var objectSerializer = new ObjectSerializer(type => ObjectSerializer.DefaultAllowedTypes(type)
    || type.FullName.StartsWith("MyNamespace"));
BsonSerializer.RegisterSerializer(objectSerializer);

Para permitir la serialización de tipos anónimos, agrega la expresión booleana type.FullName.StartsWith("<>f__AnonymousType")) a tu delegado, como se muestra en el ejemplo siguiente:

var objectSerializer = new ObjectSerializer(type => ObjectSerializer.DefaultAllowedTypes(type)
    || type.FullName.StartsWith("<>f__AnonymousType"));
BsonSerializer.RegisterSerializer(objectSerializer);

Debes crear y registrar tu ObjectSerializer al inicio de tu programa, antes de hacer cualquier otra cosa.

¿En qué se diferencia el controlador .NET/C# del proveedor MongoDB Entity Framework Core?

El driver .NET/C# es una librería que expone la funcionalidad de MongoDB directamente e incluye un proveedor LINQ con proyecciones, operaciones de grupo y una asignación flexible. El driver incluye funcionalidades como las siguientes:

• Transacciones

• Operaciones masivas

• consultas LINQ

• Operaciones que modifican directamente la base de datos

• Operaciones de agregación

• Mapeo personalizado

El Proveedor de Entity Framework Core le permite utilizar Entity Framework Core de Microsoft con MongoDB en sus aplicaciones .NET/C#. El proveedor de Entity Framework Core admite el seguimiento de cambios, operaciones LINQ basadas en entidades y modelado que resulta familiar a los usuarios de Entity Framework Core. El proveedor incluye funcionalidades tales como las siguientes:

• Seguimiento inteligente de objetos

• Operaciones LINQ basadas en entidades

• Modelado y mapeo de Entity Framework con la API fluida

• Actualizaciones automáticas de la base de datos a través del seguimiento de cambios