Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Configurar operaciones en conjuntos de réplicas

En esta guía, puedes aprender cómo configurar las opciones de nivel de confirmación de escritura (write concern), nivel de consistencia de lectura y preferencia de lectura para modificar la manera en que el controlador Java ejecuta operaciones de lectura y escritura en conjuntos de réplicas.

Puedes establecer las opciones de nivel de confirmación de escritura (write concern), nivel de consistencia de lectura y preferencia de lectura en los siguientes niveles:

  • Cliente, que establece el por defecto para todas las ejecuciones de operaciones, a menos que se anule

  • transacción

  • Database

  • Colección

Esta lista también indica el orden creciente de prioridad de las configuraciones de opciones. Por ejemplo, si se establece un nivel de consistencia de lectura para una transacción, se anularán las configuraciones de nivel de consistencia de lectura heredadas del cliente.

Las opciones de nivel de confirmación de escritura (write concern), nivel de consistencia de lectura y preferencia de lectura permiten personalizar la coherencia causal y la disponibilidad de los datos en tus sets de réplicas. Para ver una lista completa de estas opciones, consulte las siguientes guías en el manual de MongoDB Server:

Se puede controlar cómo el driver enruta las operaciones de lectura entre los miembros del set de réplicas estableciendo una preferencia de lectura. También puedes controlar cómo el driver espera el reconocimiento de las operaciones de lectura y nivel de confirmación de escritura (write concern) en un set de réplicas configurando los concerns de lectura y nivel de confirmación de escritura (write concern).

Las siguientes secciones muestran cómo configurar estos parámetros de lectura y guardado en varios niveles.

Este ejemplo muestra cómo establecer la preferencia de lectura, la preocupación por la lectura y el nivel de confirmación de escritura (write concern) de una instancia de MongoClient pasando una instancia de MongoClientSettings al constructor. El código configura los siguientes ajustes:

  • secondary preferencia de lectura: las operaciones de lectura recuperan datos de miembros secundarios del set de réplicas.

  • LOCAL Nivel de consistencia de lectura: las operaciones de lectura devuelven los datos más recientes de la instancia sin garantizar que los datos hayan sido escritos en la mayoría de los miembros del grupo de réplicas.

  • W2 nivel de confirmación de escritura (write concern): El primario del set de réplicas y un secundario deben reconocer la operación de grabación.

MongoClient mongoClient = MongoClients.create(MongoClientSettings.builder()
.applyConnectionString(new ConnectionString("mongodb://localhost:27017/"))
.readPreference(ReadPreference.secondary())
.readConcern(ReadConcern.LOCAL)
.writeConcern(WriteConcern.W2)
.build());

Alternativamente, se pueden especificar los ajustes de lectura y guardado en el URI de conexión, que se pasa como un parámetro al constructor MongoClients:

MongoClient uriClient = MongoClients.create("mongodb://localhost:27017/?readPreference=secondary&w=2&readConcernLevel=local");

Este ejemplo muestra cómo establecer la preferencia de lectura, el nivel de consistencia de lectura y el nivel de confirmación de escritura (write concern) de una transacción pasando una instancia de TransactionOptions al método startTransaction(). Las transacciones se ejecutan dentro de sesiones, que son agrupaciones de operaciones de lectura o escritura relacionadas que se pretenden ejecutar secuencialmente. Antes de aplicar las opciones de transacción, cree una instancia de ClientSession para iniciar una sesión.

Tip

Para obtener más información sobre las sesiones, consulte Sesiones del Servidor en el manual del MongoDB Server.

El ejemplo configura los siguientes ajustes:

  • primary preferencia de lectura: Las operaciones de lectura recuperan los datos del miembro primario del set de réplicas.

  • MAJORITY nivel de consistencia de lectura: Las operaciones de lectura devuelven los datos más recientes de la instancia que se han escrito en la mayoría de los miembros del set de réplicas.

  • W1 nivel de confirmación de escritura (write concern): El miembro primario del conjunto de réplicas debe acuse de recibo de la operación de escritura.

TransactionOptions tOptions = TransactionOptions.builder()
.readPreference(ReadPreference.primary())
.readConcern(ReadConcern.MAJORITY)
.writeConcern(WriteConcern.W1)
.build();
try (ClientSession clientSession = client.startSession()) {
clientSession.startTransaction(tOptions);
// Specify transaction operations here
}

Este ejemplo muestra cómo configurar la preferencia de lectura, el nivel de consistencia de lectura y el nivel de confirmación de escritura (write concern) de una base de datos llamada test_database encadenando métodos 'setter' al método getDatabase(). El código configura los siguientes ajustes:

  • primaryPreferred preferencia de lectura: las operaciones de lectura recuperan datos del miembro primario del set de réplicas o de miembros secundarios si el primario no está disponible.

  • AVAILABLE Nivel de consistencia de lectura: las operaciones de lectura devuelven los datos más recientes de la instancia sin garantizar que los datos hayan sido escritos en la mayoría de los miembros del grupo de réplicas.

  • MAJORITY nivel de confirmación de escritura (write concern): La mayoría de todos los miembros del set de réplicas deben reconocer la operación de escritura.

MongoDatabase database = mongoClient.getDatabase("test_database")
.withReadPreference(ReadPreference.primaryPreferred())
.withReadConcern(ReadConcern.AVAILABLE)
.withWriteConcern(WriteConcern.MAJORITY);

Este ejemplo muestra cómo configurar la preferencia de lectura, el nivel de consistencia de lectura y el nivel de confirmación de escritura (write concern) de una colección llamada test_collection, encadenando métodos setters al método getCollection(). El código configura la siguiente configuración:

  • secondaryPreferred preferencia de lectura: Las operaciones de lectura recuperan datos de los miembros secundarios del set de réplicas, o de los miembros primarios si no se dispone de miembros secundarios.

  • AVAILABLE Nivel de consistencia de lectura: las operaciones de lectura devuelven los datos más recientes de la instancia sin garantizar que los datos hayan sido escritos en la mayoría de los miembros del grupo de réplicas.

  • UNACKNOWLEDGED nivel de confirmación de escritura (write concern): Los miembros del conjunto de réplicas no necesitan reconocer la operación de escritura.

MongoCollection<Document> collection = database.getCollection("test_collection")
.withReadPreference(ReadPreference.secondaryPreferred())
.withReadConcern(ReadConcern.AVAILABLE)
.withWriteConcern(WriteConcern.UNACKNOWLEDGED);

Las siguientes secciones describen formas de personalizar aún más cómo el controlador Java enruta las operaciones de lectura.

Se puede especificar una preferencia de lectura cuando se conecta a un clúster fragmentado. MongoDB utiliza particionado para dividir conjuntos de datos por rangos de claves y distribuir datos entre varias instancias de bases de datos. Un clúster particionado, o el conjunto de nodos en una implementación particionada, incluye los siguientes componentes:

  • Partición: Un set de réplicas que contiene un subconjunto de los datos particionados.

  • Mongos: Un enrutador de query que ofrece una interfaz entre tu aplicación y el clúster.

  • Servidores de configuración: Servidores que almacenan la configuración y los metadatos del clúster.

Tip

Para obtener más información sobre los clústeres compartimentados, consulte Particionado en el manual de MongoDB Server.

Al leer desde las particiones del set de réplicas, mongos aplica la preferencia de lectura especificada. La preferencia de lectura se vuelve a evaluar para cada operación.

El siguiente ejemplo muestra cómo conectarse a un clúster fragmentado y especificar una preferencia de lectura secondary en tu cadena de conexión:

MongoClient uriClient = MongoClients.create("mongodb://user:password@mongos1.example.com,mongos2.example.com/?readPreference=secondary");

En MongoDB Server, puedes aplicar etiquetas de clave-valor a los miembros del set de réplicas según cualquier criterio que elijas. A continuación, puedes usar esas etiquetas para dirigir una operación de lectura a uno o más nodos.

Por defecto, el driver de Java ignora las etiquetas al elegir un nodo del que leer. Para indicar al controlador de Java que prefiera ciertas etiquetas, pasa las etiquetas como una lista al método configurador de preferencia de lectura.

Supongamos que está conectado a un set de réplicas que contiene nodos alojados en múltiples centros de datos en todo Estados Unidos. Desea que el driver prefiera las lecturas de los miembros secundarios del set de réplicas en el siguiente orden:

  1. Miembros del centro de datos de Nueva York, etiquetados con ("dc", "ny")

  2. Nodos del centro de datos de San Francisco, etiquetados con ("dc", "sf")

  3. Cualquier miembro secundario

Este ejemplo de código pasa una lista de etiquetas que representan a los miembros anteriores del set de réplicas al método setter ReadPreference.secondary(). Luego, el código pasa la información de preferencia de lectura al método withReadPreference() para establecer el orden de lectura en la base de datos:

TagSet tag1 = new TagSet(new Tag("dc", "ny"));
TagSet tag2 = new TagSet(new Tag("dc", "sf"));
TagSet tag3 = new TagSet();
ReadPreference readPref= ReadPreference.secondary(Arrays.asList(tag1, tag2, tag3));
MongoDatabase database = mongoClient.getDatabase("test_database")
.withReadPreference(readPref);

Al conectarse a un clúster o a un set de réplicas, el driver de Java utiliza el balanceo de carga para gestionar las solicitudes de lectura. El balanceo de carga permite que el controlador distribuya estas solicitudes entre varios servidores, lo que evita sobrecargar cualquier servidor y garantiza un rendimiento óptimo.

Al conectarse a un clúster fragmentado, el controlador Java determina la instancia mongos más cercana calculando cuál tiene el menor tiempo de ida y vuelta en la red. Luego, el controlador determina la ventana de latencia añadiendo el tiempo promedio de ida y vuelta de este mongos al valor localThresholdMS. El controlador equilibra la carga de las solicitudes entre hasta dos instancias de mongos seleccionadas al azar que se encuentran dentro de la ventana de latencia. Para cada solicitud, el driver elige el servidor con la carga de operación más baja determinando su valor de operationCount.

Al conectarse a un set de réplicas, el driver de Java primero selecciona los miembros del set de réplicas según la preferencia de lectura. Luego, el conductor sigue el mismo proceso que se describe en el párrafo anterior. Después de calcular la ventana de latencia, el driver selecciona hasta dos miembros del set de réplicas aleatorios dentro de la ventana y elige al nodo con el menor valor de operationCount para recibir la solicitud.

Tip

Para obtener más información sobre el balanceo de carga, consulte Balanceador de clúster en el manual de MongoDB Server.

Para aprender cómo personalizar el comportamiento de selección de servidor del driver, consulta Configuración del clúster en la guía Especificar la configuración de MongoClient.

El controlador de Java utiliza el valor umbral local para calcular la ventana de latencia para la selección de servidores. Este valor determina los servidores que son elegibles para recibir solicitudes de lectura y guardado.

Cuando se conecta a un set de réplicas con una preferencia de lectura que no es primaria, el driver lee del miembro elegible más cercano del set de réplicas dentro de la ventana de latencia. Al conectarse a un clúster fragmentado, el controlador selecciona entre todas las instancias mongos accesibles dentro de la ventana de latencia. Para aprender sobre los modos de preferencia de lectura, consulte Preferencia de lectura.

Por defecto, el controlador utiliza únicamente los servidores cuyos tiempos de ping se encuentren dentro de 15 milisegundos del servidor elegible más cercano.

Por ejemplo, supongamos que su set de réplicas tiene cinco nodos y el nodo más cercano tiene un tiempo de ping de 5 milisegundos. Con el valor por defecto de localThresholdMS de 15 milisegundos, solo los nodos con un tiempo de ping de 20 milisegundos o menos están dentro de la ventana de latencia, como se muestra en la tabla siguiente:

host
Tipo
Tiempo de ping
Dentro de la Ventana de Latencia

host1

Primario

5ms

host2

secundario

9ms

host3

secundario

13ms

host4

secundario

24ms

No

host5

secundario

42ms

No

Para ajustar la ventana de latencia, configura la opción localThreshold en una instancia MongoClientSettings o la opción localThresholdMS en tu URI de conexión.

Nota

Al seleccionar miembros del set de réplicas de una sola instancia de mongos, el driver de Java ignora la opción localThresholdMS. En este caso, use la opción de línea de comandos localThreshold.

El siguiente ejemplo se conecta a un set de réplicas y especifica un umbral local de 35 milisegundos. Selecciona la pestaña MongoClientSettings o Connection URI para ver el código correspondiente de cada enfoque:

MongoClient client = MongoClients.create(MongoClientSettings.builder()
.applyConnectionString(new ConnectionString("mongodb://localhost:27017/"))
.applyToClusterSettings(builder -> builder.localThreshold(35, TimeUnit.MILLISECONDS))
.build());
String connectionString = "mongodb://localhost:27017/?replicaSet=repl0&localThresholdMS=35";
MongoClient client = MongoClients.create(connectionString);

En el ejemplo anterior, el driver de Java distribuye las lecturas entre los nodos correspondientes dentro de 35 milisegundos del tiempo de ping del nodo más cercano.

Para aprender más sobre cualquiera de los métodos o tipos analizados en esta guía, consulta la siguiente documentación de API: