Esta página describe estrategias comunes para la solución de problemas clúster particionado deployments.
Antes de comenzar
A partir de MongoDB 8.0, puedes utilizar el
directShardOperations rol para realizar operaciones de mantenimiento que requieren ejecutar comandos directamente en una partición.
Advertencia
Ejecutar comandos usando el rol directShardOperations puede hacer que su clúster deje de funcionar correctamente y puede causar corrupción de datos. Utiliza el rol directShardOperations únicamente con fines de mantenimiento o bajo la orientación del soporte de MongoDB. Deja de usar el rol directShardOperations cuando termines de realizar operaciones de mantenimiento.
Los servidores de aplicaciones o las instancias mongos dejan de estar disponibles
Si cada servidor de aplicación tiene su propia instancia mongos, otros servidores de aplicación pueden seguir accediendo a la base de datos. Además, mongos las instancias no mantienen un estado persistente y pueden reiniciarse y quedar inaccesibles sin perder ningún estado o dato. Cuando se inicia una instancia de mongos, recupera una copia de la base de datos de configuración y puede comenzar a enrutar consultas.
Un nodo deja de estar disponible en un set de réplicas de particiones
Los conjuntos de réplicas proporcionan alta disponibilidad para particiones. Si el mongod no disponible es un primario, entonces el set de réplicas elegirá un nuevo primario. Si el mongod no disponible es un secundario, y se desconecta, el primario y el secundario continuarán conservando todos los datos. En un set de réplicas de tres nodos, incluso si un único nodo del set experimenta una falla catastrófica, otros dos nodos tienen copias completas de los datos. [1]
Siempre investiga las interrupciones y errores de disponibilidad. Si un sistema no es recuperable, reemplázalo y crea un nuevo nodo del set de réplicas lo antes posible para reemplazar la redundancia perdida.
| [1] | Si una réplica secundaria no disponible se vuelve disponible mientras aún tiene entradas oplog actuales, puede recuperar el último estado del conjunto usando el proceso de replicación normal; de lo contrario, debe realizar una sincronización inicial. |
Todos los miembros de una partición se vuelven indisponibles
En un clúster fragmentado, las instancias mongod y mongos supervisan los sets de réplicas en el clúster fragmentado (por ejemplo, set de réplicas de particiones, set de réplicas del servidor de configuración).
Si todos los nodos de una partición del set de réplicas no están disponibles, todos los datos almacenados en esa partición no estarán disponibles. Sin embargo, los datos en las demás particiones seguirán estando disponibles y es posible leer y guardar datos en las otras particiones. No obstante, tu aplicación debe ser capaz de manejar resultados parciales, y debe investigar la causa de la interrupción e intentar recuperar la partición tan pronto como sea posible.
Un miembro del set de réplicas del servidor de configuración se vuelve no disponible
Los sets de réplicas proporcionan alta disponibilidad para los servidores de configuración. Si un servidor de configuración no disponible es un primario, entonces el set de réplicas elegirá un nuevo primario.
Si el set de réplicas del servidor de configuración pierde su primario y no puede elegir otro, los metadatos del clúster quedan en modo de solo lectura. Todavía se pueden leer y escribir datos en las particiones, pero no se producirá ninguna migración de fragmentos ni división de fragmentos hasta que haya un primario disponible.
Nota
Para las implementaciones de producción, recomendamos desplegar el servidor de configuración y los Sets de réplicas de fragmentos en al menos tres centros de datos. Esta configuración proporciona alta disponibilidad en caso de que un solo centro de datos falle.
Nota
Todos los servidores de configuración deben estar en funcionamiento y disponibles cuando se inicie por primera vez un clúster.
El cursor falla por datos de configuración obsoletos
Una query devuelve la siguiente advertencia cuando una o más de las instancias de mongos aún no han actualizado su caché de metadatos del clúster desde la base de datos de configuración:
could not initialize cursor across all shards because : stale config detected
Esta advertencia no debería propagarse a tu aplicación. La advertencia se repetirá hasta que todas las instancias de mongos actualicen sus cachés. Para forzar que una instancia actualice su caché, ejecuta el comando flushRouterConfig.
Claves de partición
Para solucionar una clave de partición, consulte Solución de problemas de claves de partición.
Disponibilidad del clúster
Para garantizar la disponibilidad del clúster:
Cada partición debe ser un set de réplicas; si una instancia específica de
mongodfalla, los miembros del set de réplicas elegirán otro para que sea primario y continúen la operación. Sin embargo, si una partición completa no se puede alcanzar o falla por alguna razón, esos datos no estarán disponibles.La clave de partición debería permitir que el
mongosaísle la mayoría de las operaciones a una sola partición. Si las operaciones pueden ser procesadas por una única partición, el fallo de una única partición solo dejará indisponible parte de los datos. Si las operaciones necesitan acceder a todas las particiones para queries, la falla de una sola partición hará que todo el clúster esté inoperable.
Config Database String Error
Los servidores de configuración deben implementarse como sets de réplicas. Las mongos instancias para el clúster deben especificar el mismo nombre de set de réplicas del servidor de configuración, pero pueden especificar el nombre del host y el puerto de diferentes nodos del set de réplicas.
Con versiones anteriores de clústeres de MongoDB que utilizan una topología de tres instancias mongod espejadas para los servidores de configuración, las instancias mongos en un clúster deben especificar la misma string configDB.
Evite el tiempo de inactividad al mover los servidores de configuración
Usa CNAMEs para identificar los servidores de configuración ante el clúster, de modo que puedas cambiar el nombre y la numeración sin tiempo de inactividad.
moveChunk commit failed Error
Al final de una migración de fragmentos, la partición debe conectarse a la base de datos de configuración para actualizar el registro de la partición en los metadatos del clúster. Si la partición no logra conectarse a la base de datos de configuración, MongoDB reporta el siguiente error:
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"
Cuando esto ocurre, el miembro primario del set de réplicas de la partición se cierra para proteger la coherencia de los datos. Si un miembro secundario puede acceder a la base de datos de configuración, los datos en la partición vuelven a ser accesibles después de una elección.
El usuario tendrá que resolver de forma independiente el fallo en la migración de fragmentos. Si encuentras este problema, pide al MongoDB Community o MongoDB Support para abordar este problema.
Metadatos de particionado inconsistentes
A partir de MongoDB 7.0, el comando checkMetadataConsistency está disponible para verificar los metadatos de particionado en busca de inconsistencias y corrupciones debidas a errores en versiones anteriores de MongoDB.
Las inconsistencias en los metadatos de particionado pueden originarse en casos tales como:
Clústeres actualizados desde una versión anterior a la 5.0 de MongoDB que pueden tener datos dañados debido a operaciones DDL anteriores.
Intervenciones manuales, como manipular la base de datos de configuración o eludir
mongospara guardar directamente en una partición.Operaciones de mantenimiento, como procedimientos de actualización o degradación.
Estas incoherencias pueden provocar resultados de query incorrectos o pérdida de datos.
Para verificar si hay inconsistencias en los metadatos de particionado, ejecute el comando checkMetadataConsistency:
db.runCommand( { checkMetadataConsistency: 1 } )
{ cursor: { id: Long("0"), ns: "test.$cmd.aggregate", firstBatch: [ { type: "MisplacedCollection", description: "Unsharded collection found on shard different from database primary shard", details: { namespace: "test.authors", shard: "shard02", localUUID: new UUID("1ad56770-61e2-48e9-83c6-8ecefe73cfc4") } } ], }, ok: 1 }
Los documentos devueltos por el comando checkMetadataConsistency indican las inconsistencias identificadas por MongoDB en los metadatos de particionado del clúster.
Para obtener información sobre documentos de inconsistencias devueltos por el comando checkMetadataConsistency, consulta Tipos de Inconsistencias.