Esta página describe estrategias comunes para la resolución de problemas. Implementacionesde clúster fragmentado.
Antes de comenzar
A partir de MongoDB 8.0, puedes usar 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 aplicaciones tiene su propia instanciamongos, los demás servidores de aplicaciones pueden seguir accediendo a la base de datos. Además, las instanciasmongosno mantienen un estado persistente y pueden reiniciarse y dejar de estar disponibles sin perder el estado ni los datos. Cuando se inicia una instanciamongos, recupera una copia de la base de datos de configuración y puede empezar a enrutar consultas.
Un solo miembro deja de estar disponible en un conjunto de réplicas de fragmentos
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, mongod las mongos instancias y monitorean los conjuntos de réplicas en el clúster fragmentado (por ejemplo, conjuntos de réplicas de fragmentos, conjunto de réplicas del servidor de configuración).
Si todos los miembros de un fragmento del conjunto de réplicas no están disponibles, todos los datos almacenados en ese fragmento no estarán disponibles. Sin embargo, los datos de todos los demás fragmentos permanecerán disponibles, y será posible leer y escribir datos en ellos. No obstante, su aplicación debe ser capaz de procesar resultados parciales, por lo que debe investigar la causa de la interrupción e intentar recuperar el fragmento lo antes posible.
Un miembro del conjunto de réplicas del servidor de configuración deja de estar 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 servidor de configuración del conjunto de réplicas pierde su servidor principal y no puede elegir uno, los metadatos del clúster pasan a ser de solo lectura. Aún se pueden leer y escribir datos desde los fragmentos, pero no se realizarán migraciones ni divisiones de fragmentos hasta que haya un servidor principal 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 problemas con una clave de fragmento, consulte Solucionar problemas de claves de fragmento.
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
Utilice CNAME para identificar sus servidores de configuración en el clúster, de modo que pueda cambiar el nombre y la numeración de sus servidores de configuració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 Comunidad MongoDB o Soporte MongoDB para abordar este problema.
Metadatos de particionado inconsistentes
A partir de MongoDB 7.0, el comando está disponible para verificar los metadatos de fragmentación en busca de inconsistencias y corrupciones debido a errores en versiones anteriores de checkMetadataConsistency 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 fragmentación, ejecute el checkMetadataConsistency comando:
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 indican las inconsistencias identificadas por MongoDB en los metadatos de fragmentación del checkMetadataConsistency clúster.
Para obtener información sobre documentos de inconsistencias devueltos por el comando checkMetadataConsistency, consulta Tipos de Inconsistencias.