Preguntas frecuentes

¿Por qué recibo errores al conectarme a MongoDB?

Si tiene problemas para conectarse a una implementación de MongoDB, consulte la Guía de solución de problemas de conexión para obtener posibles soluciones.

¿Cómo funciona la agrupación de conexiones en el controlador .NET/C#?

Cada MongoClient Cada instancia cuenta con un grupo de conexiones integrado para cada servidor de su topología MongoDB. Los grupos de conexiones abren sockets a demanda para admitir operaciones simultáneas de MongoDB en su aplicación multihilo.

El tamaño máximo de cada grupo de conexiones se establece mediante la opción MaxConnectionPoolSize, cuyo valor predeterminado es 100. Si el número de conexiones en uso a un servidor alcanza MaxConnectionPoolSize, la siguiente solicitud a ese servidor esperará hasta que haya una conexión disponible. El siguiente diagrama ilustra una vista general de cómo MongoClient administra un grupo de conexiones:

Además de los sockets necesarios para los subprocesos de su aplicación, cada instancia MongoClient abre dos sockets adicionales por servidor en su topología de MongoDB para supervisar el estado del servidor. Por ejemplo, un cliente conectado a un conjunto 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), puede haber un máximo de 106 conexiones en uso. Si la aplicación usa una preferencia de lectura para consultar los nodos secundarios, esos grupos de conexiones crecen y puede haber 306 conexiones en total.

Para admitir una gran cantidad de subprocesos MongoDB simultáneos dentro de un proceso, puede aumentar MaxConnectionPoolSize.

El controlador tiene una cola de espera que limita el número de subprocesos que pueden esperar una conexión. El tamaño de la cola de espera se determina mediante la opción WaitQueueMultiple, cuyo valor predeterminado es 5. Para calcular el tamaño máximo de la cola de espera, el controlador multiplica WaitQueueMultiple por MaxConnectionPoolSize. Si utiliza el valor predeterminado para cada opción, el tamaño de la cola de espera será 500. También puede configurar el tamaño de la cola de espera especificando la opción WaitQueueSize, que anula las demás opciones. Sin embargo, no se recomienda cambiar el tamaño predeterminado de la cola de espera.

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.

• Una conexión existente se vuelve a incluir en el grupo.

• 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.

Puede establecer el número máximo de milisegundos que una conexión puede permanecer inactiva en el pool mediante la MaxConnectionIdleTime opción. Si una conexión permanece inactiva MaxConnectionIdleTime durante, el controlador la elimina. El valor predeterminado de esta opción es 10 minutos. Si el tamaño del pool es inferior MinConnectionPoolSize a, el controlador elimina y reemplaza la conexión inactiva.

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

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

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

Cree un cliente para cada proceso y reutilícelo para todas las operaciones. Es un error común crear un cliente para cada solicitud, lo cual resulta muy ineficiente.

No existe ninguna forma compatible para terminar un MongoClient en el controlador.

¿Por qué el controlador genera un tiempo de espera durante la selección del servidor?

Cada operación del controlador requiere que se seleccione un servidor en buen estado que cumpla con los criterios de selección. Si no se selecciona un servidor adecuado dentro del tiempo límite de selección, el controlador genera una excepción de tiempo límite de selección. La excepción es similar a la 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 contiene AreSessionsSupportedServerSelector, LatencyLimitingServerSelector y OperationsCountServerSelector).

3. Vista actual del controlador de la topología del clúster. La lista de servidores que el controlador reconoce es fundamental en esta vista. Cada descripción de servidor contiene una descripción exhaustiva de su estado actual, incluyendo información sobre un punto final, la versión del servidor, el tipo de servidor y su estado actual. Si el servidor presenta problemas al informar su estado, HeartbeatException contiene la excepción del último latido fallido. 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 de latido son comunes:

   • No connection could be made because the target machine actively refused itEl controlador no puede ver este nodo del clúster. Esto puede deberse a que el nodo del clúster ha fallado, a que un firewall impide que el tráfico de red llegue al nodo o puerto del clúster, o a que algún otro error de red impide que el tráfico se enrute correctamente al nodo del clúster.

   • Attempted to read past the end of the streamEste error ocurre cuando el controlador no puede conectarse a los nodos del clúster debido a un error de red, un firewall mal configurado u otro problema de red. Para solucionar esta excepción, asegúrese de que todos los nodos del clúster sean accesibles. Este error suele ocurrir cuando la dirección IP del equipo cliente no está configurada en la lista de acceso de IP de Atlas, que se encuentra en Network Access Pestaña para su proyecto Atlas.

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

¿Debo utilizar LINQ, clases Builder o documentos BSON al consultar documentos?

Si está acostumbrado a programar en C#, considere usar LINQ por su similitud con la programación en C# nativo. Si tiene experiencia previa con otros controladores de MongoDB, considere usar clases de compilación por su consistencia con otros controladores. Los documentos BSON ofrecen la mayor flexibilidad y se traducen con mayor facilidad a otros lenguajes de programación, pero son menos idiomáticos para C# y no comprueban errores de tipo en tiempo de compilación.

Le recomendamos experimentar con cada enfoque para determinar el mecanismo más adecuado para sus necesidades. Para obtener más información sobre la visualización de consultas LINQ y de clases de constructor, consulte el Analizador de C# de MongoDB. Para obtener ayuda con la creación de consultas de documentos BSON, consulte la documentación de MongoDB Compass.

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

Cada expresión LINQ o Builder debe estar disponible en la API de consulta. Esto no siempre es posible por las siguientes razones:

1. Intenta usar una función de .NET/C# que no tiene una representación equivalente en MongoDB. Por ejemplo, .NET/C# y MongoDB tienen una semántica diferente en cuanto a las intercalaciones.

2. El controlador no admite una transformación específica de una expresión LINQ o Builder a MQL (lenguaje de consulta MongoDB). Esto puede deberse a que la consulta proporcionada no tiene traducción a MQL o a que aún no se ha implementado una función en el controlador.

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

1. Intente configurar el nuevo proveedor LINQ.3 El3 proveedor LINQ incluye muchas correcciones y nuevas funciones con respecto al2 proveedor LINQ.

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

3. Intente simplificar su consulta siempre que sea posible.

4. Proporcione una consulta como BsonDocument o una cadena JSON. Todas las clases de definición de controlador, como FilterDefinition, ProjectionDefinition y PipelineDefinition, admiten la conversión implícita desde BsonDocument o una cadena JSON. Por ejemplo, los siguientes filtros son equivalentes cuando se usan en una consulta 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 objetos se pueden serializar?

El ObjectSerializer permite la serialización y deserialización únicamente de tipos considerados seguros. Al construir un ObjectSerializer, se puede pasar un delegado de tipo Func<Type, bool>. Este delegado acepta un tipo de objeto 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.

¿Cuál es la diferencia entre el controlador .NET/C# y el proveedor principal de MongoDB Entity Framework?

El controlador .NET/C# es una biblioteca que expone directamente la funcionalidad de MongoDB e incluye un proveedor LINQ con proyecciones, operaciones de grupo y mapeo flexible. El controlador incluye características como las siguientes:

• Transacciones

• Operaciones a granel

• Consultas LINQ

• Operaciones que modifican directamente la base de datos

• Operaciones de agregación

• Mapeo personalizado

El proveedor de Entity Framework Core permite usar Entity Framework Core de Microsoft con MongoDB en sus aplicaciones .NET/C#. Este proveedor admite el seguimiento de cambios, las operaciones LINQ basadas en entidades y el modelado habitual para los usuarios de Entity Framework Core. El proveedor incluye características 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