Para escribir código de aplicación que aproveche al máximo las capacidades de MongoDB y gestione con elegancia las elecciones de set de réplicas, debes:
Instala las últimas Librerías de clientes.
Utilice una cadena de conexión que especifique todos los hosts.
Utilice escrituras reintentables y lecturas reintentables.
Utiliza un
majoritynivel de confirmación de escritura (write concern) y un nivel de consistencia de lectura que tenga sentido para tu aplicación.Gestiona los errores en tu aplicación.
Instale las Librerías de clientes más recientes
Primero, instala las bibliotecas cliente más recientes para tu lenguaje desde Bibliotecas Cliente de MongoDB. Estas bibliotecas conectan tu aplicación con la base de datos y reenvían las consultas. El uso de las bibliotecas cliente más recientes habilita las funciones más recientes de MongoDB.
Luego, en tu aplicación, importa la dependencia:
Cadenas de conexión
Utilice una cadena de conexión que especifique todos los hosts de su implementación para conectar su aplicación a la base de datos. Si su implementación realiza una elección de conjunto de réplicas y se elige un nuevo primario, una cadena de conexión que especifique todos los hosts de su implementación detectará el nuevo primario sin necesidad de lógica de aplicación.
Puedes especificar todos los hosts en tu implementación utilizando:
el formato de cadena de conexión estándar, o
La cadena de conexión también puede especificar opciones, en particular retryWrites y writeConcern.
Tip
Para obtener ayuda con el formateo de tu cadena de conexión, consulta Conectar a una implementación mediante una biblioteca cliente de MongoDB.
Utiliza tu cadena de conexión para crear un cliente de MongoDB en la aplicación:
Escrituras y lecturas reintentables
Nota
A partir de la versión 4.2 de MongoDB y con bibliotecas cliente compatibles con 4.2, MongoDB reintenta tanto las escrituras como las lecturas una vez por defecto.
Escrituras reintentables
Utilice escrituras reintentables para volver a intentar ciertas operaciones de escritura una sola vez si fallan.
Reintentar las escrituras exactamente una vez es la mejor estrategia para manejar errores transitorios de red y elección del set de réplicas en las que la aplicación no puede encontrar temporalmente un nodo primario en buen estado. Si el reintento tiene éxito, la operación en su conjunto es exitosa y no se devuelve ningún error. Si la operación falla, es probable que sea debido a:
Un error de red persistente, o
Un comando no válido.
Tip
Para obtener más información sobre cómo habilitar las escrituras reintentables, consulte Habilitación de escrituras reintentables.
Cuando una operación falla, su aplicación debe gestionar el error por sí misma.
Lecturas reintentables
Las operaciones de lectura se reintentan automáticamente una sola vez si fallan a partir de la versión 4.2 de MongoDB y con bibliotecas cliente compatibles con 4.2. No es necesario configurar la aplicación para que reintente las lecturas.
Guardar y nivel de consistencia de lectura
Puedes ajustar la coherencia y la disponibilidad de tu aplicación utilizando niveles de confirmación de escritura (write concern) y niveles de consistencia de lectura. Preocupaciones más estrictas implican que las operaciones de la base de datos esperen garantías de coherencia de datos más fuertes, mientras que el alivio de los requisitos de coherencia proporciona una mayor disponibilidad.
Ejemplo
Si su aplicación gestiona saldos monetarios, la coherencia es sumamente importante. Puedes usar majority guardar y nivel de consistencia de lectura para asegurarte de nunca leer datos obsoletos o datos que puedan ser revertidos.
Alternativamente, si tu aplicación registra datos de temperatura de cientos de sensores cada segundo, es posible que no te preocupe si lees datos que no incluyen las lecturas más recientes. Puede flexibilizar los requisitos de coherencia para proporcionar un acceso más rápido a esos datos.
Nivel de confirmación de escritura
Puedes configurar el nivel de seguridad de escritura de tu conjunto de réplicas mediante la URI de la cadena de conexión. Utiliza un nivel de seguridad de escritura majority para garantizar que tus datos se escriban correctamente en la base de datos y se almacenen de forma persistente. Esta es la configuración predeterminada recomendada y suficiente para la mayoría de los casos.
Cuando use un nivel de confirmación de escritura (write concern) que requiera confirmación, como majority, también puede especificar un límite máximo de tiempo para que las escrituras alcancen ese nivel de confirmación:
El parámetro de cadena de conexión
wtimeoutMSpara todas las escrituras, oLa opción wtimeout para una única operación de escritura.
El uso o no de un límite de tiempo y el valor que utilices dependen del contexto de tu aplicación.
Tip
Para obtener más información sobre cómo configurar los niveles de protección contra escritura, consulte Opciones de protección contra escritura.
Importante
Si no se especifica un límite de tiempo para las escrituras y el nivel de confirmación de escritura es inalcanzable, la operación de escritura nunca se completará.
readConcern
Puedes configurar el nivel de seguridad de lectura de tu conjunto de réplicas mediante la URI de la cadena de conexión. El nivel ideal depende de los requisitos de tu aplicación, pero el valor predeterminado es suficiente para la mayoría de los casos. No se requiere ningún parámetro en la cadena de conexión para usar el nivel de seguridad de lectura predeterminado.
Especificar un nivel de consistencia de lectura puede mejorar las garantías sobre los datos que tu aplicación recibe de la base de datos.
Tip
Para obtener más información sobre cómo configurar los niveles de preocupación de lectura, consulte Opciones de preocupación de lectura.
Nota
La combinación específica de operaciones de lectura y escritura que utiliza su aplicación afecta a las garantías del orden de las operaciones. Esto se denomina consistencia causal. Para obtener más información sobre las garantías de consistencia causal, consulte Consistencia causal y Operaciones de lectura y escritura.
Error Handling
Los comandos no válidos, las interrupciones de red y los errores de red que no se gestionan mediante intentos de escritura reintentables generan errores. Consulte la documentación de la API de su biblioteca cliente para obtener más detalles sobre los errores.
Por ejemplo, si una aplicación intenta insertar un documento con un _id duplicado, la biblioteca cliente retorna un error que incluye:
Sin un manejo adecuado de errores, un error podría impedir que tu aplicación realice el procesamiento de solicitudes hasta que se reinicie.
Tu aplicación debe gestionar errores sin fallos ni efectos secundarios. En el ejemplo anterior de una aplicación que inserta un duplicado _id, esa aplicación podría gestionar los errores de la siguiente manera:
La operación de inserción en este ejemplo arroja un error de "clave duplicada" la segunda vez que se invoca porque el campo _id debe ser único. La aplicación captura el error, el cliente es notificado y la aplicación continúa ejecutándose. Sin embargo, la operación de inserción falla y queda a criterio del usuario decidir si mostrar un mensaje, reintentar la operación o hacer otra cosa.
Siempre se deben registrar los errores. Las estrategias comunes para el procesamiento adicional de errores incluyen:
Devuelva el error al cliente junto con un mensaje de error. Esta es una buena estrategia cuando no se puede resolver el error y es necesario informar al usuario que no se puede completar una acción.
Escribe en una base de datos de copias de seguridad. Esta es una buena estrategia cuando no puedes resolver el error pero no quieres arriesgarte a perder los datos de la solicitud.
Vuelva a intentar la operación más allá del único intento predeterminado. Esta es una buena estrategia cuando puede solucionar la causa de un error mediante programación y luego volver a intentarlo.
Debe seleccionar las mejores estrategias para el contexto de su aplicación.
Ejemplo
En el ejemplo de un error de clave duplicada, debe registrar el error pero no volver a intentar la operación porque nunca tendrá éxito. En su lugar, puedes guardar en una base de datos alternativa y revisar el contenido de esa base de datos en un momento posterior para garantizar que no se pierda ninguna información. El usuario no necesita hacer nada más y los datos están registrados, por lo que puedes optar por no enviar un mensaje de error al cliente.
Planificación para errores de red
Devolver un error puede ser conveniente cuando una operación, de otro modo, nunca se completaría e impediría que la aplicación ejecutara nuevas operaciones. Puede usar el método maxTimeMS para establecer un límite de tiempo para cada operación, devolviendo un error que la aplicación deberá gestionar si se supera dicho límite.
El límite de tiempo que se establezca para cada operación depende del contexto de esa operación.
Ejemplo
Si tu aplicación lee y muestra información de producto sencilla desde una colección inventory, puedes tener la confianza razonable de que esas operaciones de lectura solo toman un momento. Una query que se ejecuta inusualmente durante mucho tiempo es un buen indicador de que hay un problema de red persistente. Configurar maxTimeMS en esa operación a 5000, o 5 segundos, significa que tu aplicación recibe retroalimentación tan pronto como estés seguro de que hay un problema de red.
Aplicación de ejemplo resiliente
La siguiente aplicación de ejemplo reúne las recomendaciones para crear aplicaciones resilientes.
La aplicación es una API simple de registros de usuarios que expone dos puntos finales en http://localhost:3000:
Método | Endpoint | Descripción |
|---|---|---|
|
| Obtiene una lista de nombres de usuario de una colección |
|
| Requiere un |