Solución de problemas de un clúster fragmentado de MongoDB

Selección de claves fragmentadas y disponibilidad de clúster

La fragmentación implica dividir los datos en pequeños grupos llamados fragmentos para reducir la carga de trabajo general para un rendimiento determinado operación. Esta agrupación se logra mediante la selección de una clave óptima, que es principalmente la parte más importante antes de la fragmentación. Una clave óptima debe garantizar:

1. Mongos puede aislar la mayoría de las consultas a un mongod específico. Si, por ejemplo, se someten más operaciones a un solo fragmento, la falla de ese fragmento solo hará que los datos asociados con él estén ausentes en ese momento. Es recomendable seleccionar una clave de fragmento que proporcione más fragmentos para reducir la cantidad de datos no disponibles en caso de que el fragmento falle.
2. MongoDB podrá dividir los datos de manera uniforme entre los fragmentos. Esto garantiza que las operaciones de rendimiento también se distribuirán de manera uniforme, lo que reduce las posibilidades de fallas debido a un mayor estrés de la carga de trabajo.
3. Escriba escalabilidad en todo el clúster para garantizar una alta disponibilidad. Cada fragmento debe ser un conjunto de réplicas en el sentido de que, si una determinada instancia de mongod falla, los miembros restantes del conjunto de réplicas pueden elegir a otro miembro para que sea el principal, lo que garantiza la continuidad operativa.

Si, en cualquier caso, un fragmento dado tiene tendencia a fallar, comience por verificar cuántas operaciones de rendimiento está sujeto y considere seleccionar una mejor clave de fragmentación para tener más fragmentos.

¿Y si? La instancia de Mongos se vuelve ausente

Primero verifique si se está conectando al puerto correcto, ya que es posible que haya cambiado sin saberlo. Por ejemplo, en la implementación con la plataforma de AWS, existe la posibilidad de que se produzca este problema debido a los grupos de seguridad que pueden no permitir conexiones en ese puerto. Para una prueba inmediata, intente especificar el host:puerto completo para asegurarse de que está utilizando una interfaz de bucle invertido. Lo bueno es que si cada servidor de aplicaciones tiene su propia instancia de mongos, los servidores de aplicaciones pueden continuar accediendo a la base de datos. Además, las instancias de mongos tienen sus estados alterados con el tiempo y pueden reiniciarse sin perder necesariamente los datos. Cuando la instancia se vuelva a conectar, recuperará una copia de la base de datos de configuración y comenzará a enrutar las consultas.

Asegúrese de que el puerto al que intenta volver a conectarse tampoco esté ocupado por otro proceso.

¿Y si? Un miembro se ausenta del conjunto de réplicas de fragmentos

Comience comprobando el estado del fragmento ejecutando el comando sh.status(). Si el resultado devuelto no tiene el ID de clúster, entonces el fragmento no está disponible. Investigue siempre las interrupciones y fallas de disponibilidad y, si no puede recuperarlo en el menor tiempo posible, cree un nuevo miembro para reemplazarlo tan pronto como sea posible para evitar más pérdidas de datos.

Si un miembro secundario deja de estar disponible pero tiene entradas de oplog actuales, cuando se vuelve a conectar puede ponerse al día con el último estado establecido mediante la lectura de los datos actuales del registro de operaciones como proceso de replicación normal. Si no puede replicar los datos, debe realizar una sincronización inicial utilizando cualquiera de estas dos opciones...

1. Reinicie mongod con un directorio de datos vacío y deje que la función de sincronización inicial normal de MongoDB restaure los datos. Sin embargo, este enfoque tarda mucho en copiar los datos, pero es bastante sencillo.
2. Reinicie la máquina host con una copia de un directorio de datos reciente de otro miembro del conjunto de réplicas. Proceso rápido pero con pasos complicados

La sincronización inicial permitirá a MongoDB...

1. Clonar todas las bases de datos disponibles excepto la base de datos locales. Asegúrese de que el miembro de destino tenga suficiente espacio en disco en la base de datos local para almacenar temporalmente los registros de oplog mientras se copian los datos.
2. Aplicar todos los cambios al conjunto de datos usando el oplog de la fuente. El proceso se completará solo si el estado de la réplica cambia de INICIO2 a SECUNDARIO.

¿Y si? Todos los miembros de un conjunto de réplicas están ausentes

Los datos contenidos en un fragmento no estarán disponibles si todos los miembros de un fragmento de conjunto de réplicas desaparecen. Dado que los otros fragmentos permanecen disponibles, las operaciones de lectura y escritura aún son posibles, excepto que la aplicación se servirá con datos parciales. Deberá investigar la causa de las interrupciones e intentar reactivar el fragmento lo antes posible. Compruebe qué perfilador de consultas o el método de explicación que podría haber llevado a ese problema.

¿Y si? Los datos de configuración obsoletos conducen a errores del cursor

A veces, una instancia de mongos puede tardar mucho en actualizar la memoria caché de metadatos desde la base de datos de configuración, lo que genera una consulta que regresa la advertencia: 

could not initialize cursor across all shards because : stale config detected

Este error siempre se presentará hasta que las instancias de mongos actualicen sus cachés. Esto no debería propagarse a la aplicación. Para solucionar esto, debe forzar la actualización de la instancia ejecutando fluRouterConfig.

Para vaciar la memoria caché para una ejecución de recopilación específica

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

Para vaciar la memoria caché para ejecutar una base de datos específica 

db.adminCommand({ flushRouterConfig: "<db>" } )

Para vaciar la caché de todas las bases de datos y sus colecciones, ejecute:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

¿Y si? El servidor de configuración deja de estar disponible

El servidor de configuración en este caso se puede considerar como el miembro principal desde el cual los nodos secundarios replican sus datos. Si se ausenta, los nodos secundarios disponibles deberán elegir uno entre sus miembros para convertirse en el principal. Para evitar entrar en una situación en la que es posible que no tenga un servidor de configuración, considere distribuir los miembros del conjunto de réplicas en dos centros de datos, ya que...

• Si un centro de datos deja de funcionar, los datos seguirán estando disponibles para lecturas en lugar de ninguna operación si utilizó un solo centro de datos .
• Si el centro de datos que involucra a miembros minoritarios deja de funcionar, el conjunto de réplicas aún puede servir tanto para operaciones de escritura como de lectura.

Es recomendable distribuir los miembros en al menos tres centros de datos.

Otra posibilidad de distribución es distribuir uniformemente los miembros que contienen datos entre los dos centros de datos y los miembros restantes en la nube.

Corregir error de cadena de base de datos

A partir de MongoDB 3.4, los servidores de configuración SCCC no son compatibles con las instancias reflejadas de mongod. Si necesita actualizar su clúster fragmentado a la versión 3.4, debe convertir los servidores de configuración de SCCC a CSRS.

Evitar el tiempo de inactividad al mover servidores de configuración

El tiempo de inactividad puede ocurrir como resultado de algunos factores, como cortes de energía o frecuencias de la red, lo que resulta en la falla de un servidor de configuración en el clúster. Utilice CNAME para identificar ese servidor para cambiar el nombre o volver a numerar durante la reconexión. Si el comando de confirmación moveChunk falla durante el proceso de migración, MongoDB informará el error:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of

<N>|<NN>" and "ERROR: TERMINATING"

Esto significa que el fragmento tampoco se ha conectado a la base de datos de configuración, por lo tanto, el principal terminará este miembro para evitar la inconsistencia de los datos. Debe resolver el error de migración de fragmentos de forma independiente consultando el soporte de MongoDB. También asegúrese de proporcionar algunos recursos estables como red y energía al clúster.

Conclusión

Un clúster fragmentado de MongoDB reduce la carga de trabajo a la que habría estado sujeto un solo servidor, por lo tanto, mejora el rendimiento de operaciones de rendimiento. Sin embargo, si no se configuran correctamente algunos parámetros, como seleccionar una clave de fragmento óptima, se puede crear un desequilibrio de carga, por lo que algunos fragmentos terminan fallando.

Suponiendo que la configuración se realice correctamente, también pueden ocurrir algunos contratiempos inevitables, como cortes de energía. Para continuar brindando soporte a su aplicación con un tiempo de inactividad mínimo, considere usar al menos 3 centros de datos. Si uno falla, los demás estarán disponibles para admitir operaciones de lectura si el principal se encuentra entre los miembros afectados. También actualice su sistema al menos a la versión 3.4, ya que admite más funciones.