La migración de fragmentos de fragmentos de mongodb de 500 GB tarda 13 días: ¿es lento o normal?


9

Tengo un clúster de fragmentos de mongodb, la clave de fragmentos está en hash. Tiene 2 conjuntos de réplicas de fragmentos. Cada conjunto de réplica tiene 2 máquinas.

Hice un experimento agregando otros 2 conjuntos de réplicas de fragmentos, y comienza a reequilibrarse.

Sin embargo, después de un tiempo descubro que la migración fragmentaria es más bien lenta. Se necesitan 1 hora para mover 1,4 GB de datos.

Me preocupa, ¡significa que tengo que esperar 13 días para completar 500 GB de migración fragmentaria!

Soy nuevo en estas cosas y no tengo ni idea de si es lento, rápido o normal. Pero aún así, ese número no me convence.

Notas adicionales sobre el experimento: - uso de máquinas m3 aws medianas - no se está ejecutando ningún otro proceso, solo migración de fragmentos - instalación predeterminada de fragmentación mongodb sin configuración adicional - shardkey está utilizando hash en la identificación del objeto (_id) - tamaño máximo de fragmento 64 MB

Respuestas:


10

Actualización: abril de 2018

Esta respuesta fue correcta en el momento de la pregunta, pero las cosas han avanzado desde entonces. Desde la versión 3.4 se ha introducido el paralelismo, y el ticket al que hice referencia originalmente se ha cerrado. Para obtener más información, cubro algunos de los detalles en esta respuesta más reciente . Dejaré el resto de la respuesta tal como está porque sigue siendo una buena referencia para problemas / restricciones generales, así como válida para cualquier persona en una versión anterior.

Respuesta original

Si está interesado, le doy una explicación completa de lo que sucede con una migración fragmentaria en el curso avanzado M202 . En términos generales, digamos que las migraciones no son muy rápidas, incluso para trozos vacíos, debido a que se realiza la limpieza para asegurarse de que las migraciones funcionen en un sistema activo (esto todavía ocurre incluso si no está sucediendo nada más que el equilibrio).

Además, solo hay una migración a la vez en todo el clúster: no hay paralelismo. Por lo tanto, a pesar del hecho de que tiene dos nodos "completos" y dos nodos "vacíos", en cualquier momento dado se produce una migración como máximo (entre el fragmento con la mayor cantidad de fragmentos y el fragmento con la menor cantidad). Por lo tanto, haber agregado 2 fragmentos no te aporta nada en términos de velocidad de equilibrio y solo aumenta el número de fragmentos que se deben mover.

Para las migraciones en sí, es probable que los fragmentos tengan un tamaño de ~ 30MiB (depende de cómo haya llenado los datos, pero en general este será su promedio con el tamaño de fragmento máximo predeterminado). Puede db.collection.getShardDistribution()buscar parte de esa información y ver mi respuesta aquí para obtener más información sobre sus fragmentos.

Como no hay ninguna otra actividad en curso, para que se produzca una migración, el fragmento de destino (uno de los fragmentos recién agregados) necesitará leer ~ 30MiB de datos de los fragmentos de origen (uno de los 2 originales) y actualizar los servidores de configuración a reflejar la nueva ubicación del fragmento una vez que esté hecho. Mover 30MiB de datos no debería ser un gran obstáculo para un sistema normal sin carga.

Si es lento, hay varias razones posibles por las que ese es el caso, pero las más comunes para un sistema que no está ocupado son:

  • Source Disk I / O: si los datos no están en la memoria activa cuando se leen, se deben paginar desde el disco
  • Red: si hay latencia, limitación de velocidad, pérdida de paquetes, etc., la lectura puede tardar bastante
  • E / S de disco de destino: los datos y los índices deben escribirse en el disco, muchos índices pueden empeorarlo, pero generalmente esto no es un problema en un sistema con poca carga
  • Problemas con las migraciones que causan abortos y migraciones fallidas (problemas con los servidores de configuración, problemas con las eliminaciones en las primarias)
  • Retraso de replicación: para migraciones a conjuntos de réplicas, escribir preocupación w:2o w:majorityse usa de manera predeterminada y requiere secundarias actualizadas para satisfacerlo.

Si el sistema estaba ocupado, entonces la contención de memoria, la contención de bloqueo generalmente también sería sospechosa aquí.

Para obtener más información acerca de cuánto demoran las migraciones, si fallan, etc., eche un vistazo a las entradas en su config.changelog:

// connect to mongos
use config
db.changelog.find()

Como has visto, y como generalmente le digo a la gente cuando hago entrenamiento / educación, si sabes que necesitarás 4 fragmentos, generalmente es mejor comenzar con 4 en lugar de aumentar. Si lo hace, entonces debe tener en cuenta que agregar un fragmento puede llevar mucho tiempo, e inicialmente es un beneficio neto negativo en los recursos en lugar de una ganancia (consulte la parte II de mi serie de escollos de fragmentación para una discusión más detallada de eso).

Finalmente, para rastrear / votar / comentar la solicitud de función para mejorar el paralelismo de las migraciones fragmentadas, consulte SERVER-4355


Gracias, esto explica mucho más el mecanismo de migración de fragmentos que la documentación de mongodb.
rendybjunior

Me uniré a tu curso seguro. :) ¿Qué opinas sobre la velocidad que mencioné antes? ¿Es normal o lento? Sé que esta pregunta es relativa basada en muchos aspectos. Pero le pido su propia opinión
rendybjunior

Parece un poco lento según su descripción, pero tendría que comparar las instancias medianas para estar seguro. Su tasa actual podría ser todo lo que son capaces de hacer, o podría tener uno de los problemas que mencioné en la respuesta. Un control que puede probar es un movimiento manual: apague el equilibrador y esencialmente hágalo usted mismo para ver si hay algún problema y qué impacto tiene un movimiento en los sistemas de origen / destino. Puede encontrar los detalles relevantes sobre moveChunk aquí: docs.mongodb.org/manual/reference/method/sh.moveChunk
Adam C

Solo para agregar que la duplicación de fragmentos tiene baja prioridad en mongoDB e incluso en sistemas de alto rendimiento puede tomar algún tiempo si están ocupados.
Antonios

@Antonis: no estoy seguro de qué quiere decir con prioridad, una migración fragmentada es una lectura del fragmento de origen (igual que cualquier otra lectura) y una escritura en el fragmento de destino (con la preocupación de escritura mencionada anteriormente), no hay priorización de estas operaciones versus otros Serán lentos en sistemas ocupados, pero no debido a ninguna diferencia de prioridad inherente.
Adam C
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.