Docs Menu
Docs Home
/
Manual de MongoDB
/

Balanceador de clúster fragmentado

El balanceador de MongoDB es un proceso en segundo plano que monitorea la cantidad de Fragmentos en cada fragmento. Cuando el número de fragmentos en un fragmento determinado alcanza umbrales de migración específicos, el balanceador intenta migrar automáticamente fragmentos entre fragmentos hasta alcanzar un número igual de fragmentos por fragmento.

El procedimiento de equilibrio para clústeres fragmentados es completamente transparente para la capa de usuario y de aplicación, aunque puede haber algún impacto en el rendimiento mientras se lleva a cabo el procedimiento.

Diagrama de una colección distribuida en tres particiones. Para esta colección, la diferencia en el número de fragmentos entre las particiones alcanza los *umbrales de migración* (en este caso, 2) y activa la migración.

El equilibrador se ejecuta en el servidor principal del conjunto de réplicas del servidor de configuración (CSRS).

El proceso de balanceo se encarga de redistribuir uniformemente los fragmentos de una colección fragmentada entre los fragmentos de cada colección. De forma predeterminada, el proceso de balanceo siempre está habilitado.

Para solucionar la distribución desigual de fragmentos en una colección fragmentada, el balanceador migra fragmentos de fragmentos con mayor número a fragmentos con menor número. El balanceador migra los fragmentos hasta que se logra una distribución uniforme de fragmentos para la colección entre los fragmentos. Para obtener más información sobre la migración de fragmentos, consulte el Procedimiento de Migración de Fragmentos.

Las migraciones de fragmentos pueden afectar el espacio en disco, ya que el fragmento de origen archiva automáticamente los documentos migrados de forma predeterminada. Para obtener más información, consulte moveChunk directorio.

Las migraciones de fragmentos conllevan cierta sobrecarga en términos de ancho de banda y carga de trabajo, los cuales pueden afectar el rendimiento de la base de datos. []1 El equilibrador intenta minimizar el impacto mediante lo siguiente:

  • Restringir una partición a no más de una migración en un momento dado; es decir, una partición no puede participar en varias migraciones de fragmentos al mismo tiempo. Para migrar varios fragmentos de una partición, el balanceador migra los fragmentos uno a la vez.

    Modificado en la 3.4 versión: A partir de MongoDB,3.4 MongoDB puede realizar migraciones de fragmentos en paralelo. Teniendo en cuenta la restricción de que un fragmento puede participar como máximo en una migración a la vez, para un clúster fragmentado con n fragmentos, MongoDB puede realizar como máximo n/2 (redondeado hacia abajo) migraciones de fragmentos simultáneas.

    Consultetambién Limpieza de migración de fragmentos asincrónicos.

  • Se inicia una ronda de equilibrio solo cuando la diferencia en la cantidad de fragmentos entre el fragmento con la mayor cantidad de fragmentos para una colección fragmentada y el fragmento con la menor cantidad de fragmentos para esa colección alcanza el umbral de migración.

Puede deshabilitar el balanceador temporalmente para realizar tareas de mantenimiento, pero dejarlo deshabilitado durante períodos prolongados puede reducir el rendimiento del clúster. Para obtener más información, consulte Deshabilitar el balanceador.

También puede limitar el periodo de ejecución del balanceador para evitar que afecte al tráfico de producción.Consulte "Programar el periodo de balanceo" para obtener más información.

Nota

La especificación de la ventana de equilibrio es relativa a la zona horaria local del servidor principal del conjunto de réplicas del servidor de configuración.

Tip

[1] La operación de partición de colección puede realizar una creación y distribución inicial de fragmentos para colecciones vacías o no existentes si se han definido zonas y rangos de zonas para la colección. La creación inicial y la distribución del fragmento permiten una configuración más rápida del particionado por zonas. Tras la distribución inicial, el balanceador gestiona la distribución de fragmentos en adelante como es habitual. MongoDB admite el particionado de colecciones en índices hash compuestos. Al realizar el particionado de una colección vacía o inexistente usando claves de partición compuestas con hash, se aplican requisitos adicionales para que MongoDB pueda realizar la creación y distribución inicial de fragmentos. Consulta Predefinir zonas y rangos de zonas para una colección vacía o inexistente como ejemplo.

Añadir un fragmento a un clúster crea un desequilibrio, ya que el nuevo fragmento no tiene fragmentos. Aunque MongoDB comienza a migrar datos al nuevo fragmento inmediatamente, el clúster puede tardar un tiempo en equilibrarse. Consulta el tutorial "Añadir fragmentos a un clúster" para obtener instrucciones sobre cómo añadir un fragmento a un clúster.

Eliminar un fragmento de un clúster crea un desequilibrio similar, ya que los fragmentos que residen en él deben redistribuirse por todo el clúster. Si bien MongoDB comienza a drenar un fragmento eliminado inmediatamente, el clúster puede tardar un tiempo en equilibrarse. No apague los servidores asociados al fragmento eliminado durante este proceso.

Cuando se elimina un fragmento en un clúster con una distribución de fragmentos desigual, el equilibrador primero elimina los fragmentos del fragmento de drenaje y luego equilibra la distribución de fragmentos desigual restante.

Consulte el tutorial Eliminar fragmentos de un clúster fragmentado existente para obtener instrucciones sobre cómo eliminar de forma segura un fragmento de un clúster.

Todas las migraciones de fragmentos utilizan el siguiente procedimiento:

  1. El proceso del balanceador envía el comando al fragmento de moveChunk origen.

  2. La fuente inicia el movimiento con un comando moveChunk interno. Durante el proceso de migración, las operaciones al fragmento se dirigen a la partición de origen. La partición de origen es responsable de las operaciones de guardado entrantes para el fragmento.

  3. El fragmento de destino crea cualquier índice requerido por el origen que no exista en el destino.

  4. La partición de destino comienza a solicitar documentos en el fragmento y empieza a recibir copias de los datos. Ver también Migración y replicación de fragmento.

  5. Después de recibir el documento final en el fragmento, el fragmento de destino inicia un proceso de sincronización para garantizar que tenga los cambios en los documentos migrados que ocurrieron durante la migración.

  6. Cuando está completamente sincronizado, el fragmento de origen se conecta a la base de datos de configuración y actualiza los metadatos del clúster con la nueva ubicación del fragmento.

  7. Una vez que el fragmento de origen completa la actualización de los metadatos, y una vez que no hay cursores abiertos en el fragmento, el fragmento de origen elimina su copia de los documentos.

    Nota

    Si el balanceador necesita realizar migraciones de fragmentos adicionales desde el fragmento de origen, puede iniciar la siguiente migración sin esperar a que el proceso de migración actual finalice este paso de eliminación.Consulte Limpieza de migración de fragmentos asíncrona.

El proceso de migración garantiza la consistencia y maximiza la disponibilidad de fragmentos durante el equilibrio.

Advertencia

Las lecturas secundarias en un clúster fragmentado con migraciones pueden perder documentos

Las lecturas secundarias de larga duración en un clúster fragmentado pueden perder documentos si se están produciendo migraciones.

Antes de eliminar un fragmento durante la migración, MongoDB espera orphanCleanupDelaySecs o que las consultas en curso que involucran al fragmento se completen en el nodo principal del fragmento, lo que sea más largo. Las consultas que se ejecutaron inicialmente en un nodo principal, pero que continúan después de que este se haya reducido a un nodo secundario, se tratarán como si se hubieran ejecutado inicialmente en un nodo secundario. Es decir, el servidor solo espera orphanDelayCleanupSecs si no hay consultas dirigidas al fragmento en el nodo principal actual.

Las consultas que tienen como objetivo el fragmento y se ejecutan en recursos secundarios pueden perder documentos si estas consultas tardan más de orphanCleanupDelaySecs.

Para minimizar el impacto del balanceo en el clúster, el balanceador comienza a balancear solo después de que la distribución de datos de una colección fragmentada alcance el umbral de migración que desequilibra el clúster. Cuando el número de fragmentos en el fragmento con mayor carga supera el número óptimo de fragmentos por fragmento en más de 1 fragmentos, la colección se desequilibra y el balanceador inicia las migraciones de fragmentos. El número óptimo de fragmentos por fragmento es el número total de fragmentos en una colección fragmentada dividido entre el número de fragmentos, redondeado al entero superior más cercano. Si existen zonas, MongoDB calcula el número óptimo de fragmentos por zona.

Por ejemplo, si un usuario añade un nuevo fragmento a una colección de 10 fragmentos con 20 fragmentos cada uno, el balanceador no migra ningún dato. El número óptimo de fragmentos en cada fragmento es 200 dividido 11 entre,18.18 o, que MongoDB redondea 19 a. Dado que la diferencia entre 19 y 20 1es, el clúster está balanceado y el balanceador no migra ningún fragmento al nuevo fragmento.

Para migrar varios fragmentos de un fragmento, el balanceador migra los fragmentos uno a uno. Sin embargo, no espera a que finalice la fase de eliminación de la migración actual para iniciar la siguiente migración de fragmentos.Consulte Migración de fragmentos para conocer el proceso de migración de fragmentos y la fase de eliminación.

Este comportamiento de colas permite a las particiones descargar fragmentos más rápidamente en caso de un clúster muy desequilibrado, como al realizar cargas iniciales de datos sin pre-división y al agregar nuevas particiones.

Este comportamiento también afecta al moveChunk comando y los scripts de migración que utilizan el moveChunk comando pueden avanzar más rápidamente.

En algunos casos, las fases de eliminación pueden persistir durante más tiempo. A partir de MongoDB 4.4, las migraciones de fragmentos se han mejorado para ser más resilientes en caso de una conmutación por error durante la fase de eliminación. Los documentos huérfanos se limpian incluso si el conjunto de réplicas principal falla o se reinicia durante esta fase.

_waitForDeleteEl, disponible como ajuste para el balanceador y el comando, puede modificar el comportamiento para que la fase de eliminación de la migración actual bloquee el inicio de la siguiente migración de fragmentos.moveChunk El _waitForDelete se utiliza generalmente para pruebas internas. Para obtener más información, consulte "Esperar eliminación".

Nota

La eliminación de rango es una operación que consume muchos recursos y que puede generar un estrés significativo en la memoria caché y en E/S a medida que el clúster elimina los documentos.

Si planea mover una gran cantidad de datos, como al añadir fragmentos a un clúster o durante la distribución inicial de una colección fragmentada entre varios fragmentos, considere volver a fragmentar la colección. Las operaciones de refragmentación no requieren limpieza de rangos, lo que las hace mucho menos estresantes para el clúster.

Para obtener más información, consulte Repartir una colección.

Cambiado en la versión 3.4.

Durante la migración de fragmentos, el valor _secondaryThrottle determina cuándo continúa la migración con el siguiente documento en el fragmento.

En la config.settings colección:

  • Si la _secondaryThrottle configuración para el balanceador está establecida en una preocupación de escritura, cada documento movido durante la migración de rango debe recibir el reconocimiento solicitado antes de continuar con el siguiente documento.

  • Si la configuración _secondaryThrottle no está establecida, el proceso de migración no espera la replicación a un documento secundario y, en su lugar, continúa con el siguiente documento.

Para actualizar el _secondaryThrottle parámetro del balanceador, consulte Acelerador secundario para ver un ejemplo.

Independientemente de cualquier configuración _secondaryThrottle, ciertas fases de la migración de fragmentos siguen la siguiente política de replicación:

  • MongoDB pausa brevemente todas las lecturas y escrituras de la aplicación en la colección que se está migrando, en el fragmento de origen, antes de actualizar los servidores de configuración con la nueva ubicación del fragmento, y reanuda las lecturas y escrituras de la aplicación después de la actualización. El traslado del fragmento requiere que todas las escrituras sean confirmadas por la mayoría de los miembros del conjunto de réplicas, tanto antes como después de confirmar el traslado del fragmento en los servidores de configuración.

  • Cuando finaliza una migración de fragmento saliente y se produce una limpieza, todas las escrituras se deben replicar en la mayoría de los servidores antes de que se pueda realizar una limpieza adicional (de otras migraciones salientes) o se puedan realizar nuevas migraciones entrantes.

Para actualizar la configuración de _secondaryThrottle en la colección config.settings, ver secundario Throttle para un ejemplo.

De forma predeterminada, MongoDB no puede mover un fragmento si la cantidad de documentos en el fragmento es mayor que 1.3 veces el resultado de dividir el tamaño del fragmento configurado por el tamaño promedio del documento. incluyedb.collection.stats() el avgObjSize campo, que representa el tamaño promedio del documento en la colección.

Para fragmentos que son demasiado grandes para migrar, comenzando en MongoDB:4.4

Puede ajustar el impacto en el rendimiento de la eliminación de rangos con los parámetros y. Por rangeDeleterBatchSize rangeDeleterBatchDelayMS ejemplo:

  • Para limitar la cantidad de documentos eliminados por lote, puede establecer en un valor rangeDeleterBatchSize pequeño,32 como.

  • Para agregar un retraso adicional entre eliminaciones por lotes, puede establecer por encima del rangeDeleterBatchDelayMS valor 20 predeterminado actual de milisegundos.

Nota

Si hay operaciones de lectura en curso o cursores abiertos en la colección destinada a las eliminaciones, es posible que los procesos de eliminación de rango no puedan continuar.

De forma predeterminada, MongoDB intenta llenar todo el espacio de disco disponible con datos en cada fragmento a medida que crece el conjunto de datos. Para garantizar que el clúster siempre tenga la capacidad de gestionar el crecimiento de datos, monitoree el uso del disco y otras métricas de rendimiento.

Consulte el tutorial Cambiar el tamaño máximo de almacenamiento para un fragmento determinado para obtener instrucciones sobre cómo configurar el tamaño máximo de un fragmento.

Volver

Modifica el tamaño del rango

En esta página