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 Función para realizar operaciones de mantenimiento que requieren ejecutar comandos directamente contra un fragmento.
Advertencia
Ejecutar comandos usando el rol de directShardOperations puede hacer que su clúster deje de funcionar correctamente y puede causar corrupción de datos. Utilice el rol de directShardOperations solo para fines de mantenimiento o bajo la orientación del soporte de MongoDB. Una vez que haya terminado de realizar las operaciones de mantenimiento, deje de usar el rol de directShardOperations.
Los servidores de aplicaciones o instancias dejan de estar mongos 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 los fragmentos. Si el no disponible mongod es un servidor principal, el conjunto de réplicas elegirá uno nuevo. Si el no disponible mongod es un servidor secundario, y se desconecta, el servidor principal y el secundario seguirán almacenando todos los datos. En un conjunto de réplicas de tres miembros, incluso si un solo miembro sufre una falla catastrófica, los otros dos miembros tienen copias completas de los datos. []1
Investigue siempre las interrupciones y fallos de disponibilidad. Si un sistema es irrecuperable, reemplácelo y cree un nuevo miembro del conjunto de réplicas lo antes posible para reemplazar la redundancia perdida.
| [1] | Si un secundario no disponible se vuelve disponible mientras aún tiene entradas de registro de operaciones actuales, puede alcanzar el último estado del conjunto mediante el proceso de replicación normal; de lo contrario, debe realizar una sincronización inicial. |
Todos los miembros de un fragmento dejan de estar disponibles
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 conjuntos de réplicas proporcionan alta disponibilidad a los servidores de configuración. Si un servidor de configuración no disponible es el principal, el conjunto de réplicas elegirá uno nuevo.
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 ejecución y disponibles cuando inicie por primera vez un clúster fragmentado.
El cursor falla debido a 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 su aplicación. Se repetirá hasta que todas las instancias actualicen sus cachés. Para forzar mongos flushRouterConfig que una instancia actualice su caché, ejecute el comando.
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 fragmento debe ser un conjunto de réplicas. Si una
mongodinstancia específica de falla, los miembros del conjunto de réplicas elegirán otra como principal y continuarán la operación. Sin embargo, si un fragmento completo es inaccesible o falla por alguna razón, esos datos no estarán disponibles.La clave de fragmento debe permitir que aísle la mayoría de las operaciones en un solo fragmento. Si un
mongossolo fragmento puede procesar las operaciones, el fallo de un solo fragmento solo dejará algunos datos indisponibles. Si las operaciones necesitan acceder a todos los fragmentos para realizar consultas, el fallo de un solo fragmento dejará todo el clúster indisponible.
Config Database String Error
Los servidores de configuración deben implementarse como conjuntos de réplicas. Las instancias mongos del clúster fragmentado deben especificar el mismo nombre de conjunto de réplicas del servidor de configuración, pero pueden especificar el nombre de host y el puerto de diferentes miembros del conjunto de réplicas.
Con versiones anteriores de clústeres fragmentados de MongoDB que utilizan la topología de tres mongod instancias reflejadas para servidores de configuración, las instancias en unmongos configDB clúster fragmentado deben especificar una cadena idéntica.
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 deberá resolver el error de migración del fragmento de forma independiente. Si encuentra este problema, consulte al Comunidad MongoDB o Soporte MongoDB para abordar este problema.
Metadatos de fragmentación 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 la fragmentación de metadatos pueden originarse en casos como:
Clústeres actualizados desde una versión anterior a5.0 de MongoDB que pueden tener datos dañados de operaciones DDL anteriores.
Intervenciones manuales, como manipular la base de datos de configuración o eludir para escribir directamente en un
mongosfragmento.Operaciones de mantenimiento, como procedimientos de actualización o degradación.
Estas inconsistencias pueden generar resultados de consulta 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.