El balanceador de MongoDB es un proceso en segundo plano que monitorea la cantidad de datos en cada Fragmento para cada colecci贸n fragmentada. Cuando la cantidad de datos de una colecci贸n fragmentada en un fragmento determinado alcanza un valor espec铆fico Umbrales de migraci贸n: el balanceador intenta migrar autom谩ticamente los datos entre fragmentos y alcanzar una cantidad uniforme de datos por fragmento, respetando las zonas. De forma predeterminada, el proceso del balanceador siempre est谩 habilitado.
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.
El equilibrador se ejecuta en el servidor principal del conjunto de r茅plicas del servidor de configuraci贸n (CSRS).
Para configurar el equilibrio de recopilaci贸n para una sola recopilaci贸n, consulte
configureCollectionBalancing.
Para administrar el equilibrador de cl煤ster fragmentado, consulte Administrar el equilibrador de cl煤ster fragmentado.
Componentes internos del equilibrador
Las migraciones de rangos conllevan cierta sobrecarga en t茅rminos de ancho de banda y carga de trabajo, lo cual puede afectar el rendimiento de la base de datos. El balanceador intenta minimizar el impacto mediante:
Restringir un fragmento a una sola migraci贸n a la vez. En concreto, un fragmento no puede participar en varias migraciones de datos simult谩neamente. El balanceador migra los rangos uno a uno.
MongoDB puede realizar migraciones de datos en paralelo, pero cada fragmento puede participar en una sola migraci贸n a la vez. Para un cl煤ster fragmentado con n fragmentos, MongoDB puede realizar un m谩ximo de n/2 (redondeado hacia abajo) migraciones simult谩neas.
Consultetambi茅n Limpieza de migraci贸n de rango asincr贸nica.
Seinicia una ronda de equilibrio solo cuando la diferencia en la cantidad de datos entre el fragmento con la mayor cantidad de datos para una colecci贸n fragmentada y el fragmento con la menor cantidad de datos 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.
Agregar y eliminar fragmentos del cl煤ster
A帽adir un fragmento a un cl煤ster crea un desequilibrio, ya que el nuevo fragmento no contiene datos. 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 datos 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.
Consulta el tutorial Eliminar fragmentos de un cl煤ster para obtener instrucciones sobre c贸mo eliminar de forma segura un fragmento de un cl煤ster.
Procedimiento de migraci贸n de rango
Todas las migraciones de rango utilizan el siguiente procedimiento:
El proceso del balanceador env铆a el comando al fragmento de
moveRangeorigen.El origen inicia la migraci贸n al recibir un
moveRangecomando interno. Durante el proceso de migraci贸n, las operaciones en el rango se env铆an al fragmento de origen. Este es responsable de las operaciones de escritura entrantes en el rango.El fragmento de destino crea cualquier 铆ndice requerido por el origen que no exista en el destino.
El fragmento de destino empieza a solicitar documentos en el rango y a recibir copias de los datos. Consulte tambi茅n Migraci贸n y replicaci贸n de rangos.
Despu茅s de recibir el documento final en el rango, 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.
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 rango.
Una vez que el fragmento de origen completa la actualizaci贸n de los metadatos, y una vez que no hay cursores abiertos en el rango, 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 rango asincr贸nica.
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 a que las consultas en curso que lo involucran se completen en el nodo principal del fragmento y luego espera orphanCleanupDelaySecs segundos adicionales. Las consultas que se ejecutaron inicialmente en un nodo principal, pero que contin煤an despu茅s de que este haya pasado 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.
Umbrales de migraci贸n
Para minimizar el impacto del equilibrio en el cl煤ster, el equilibrador solo comienza a equilibrar despu茅s de que la distribuci贸n de datos de una colecci贸n fragmentada haya alcanzado ciertos umbrales.
Una colecci贸n se considera equilibrada si la diferencia de datos entre los fragmentos (para esa colecci贸n) es menor que tres veces el tama帽o del rango configurado para la colecci贸n. Para el tama帽o de rango predeterminado 128MB de, dos fragmentos deben tener una diferencia de tama帽o de datos de al menos 384MB para que se produzca una migraci贸n.
Limpieza de migraci贸n de rango asincr贸nica
Para migrar datos desde un fragmento, el balanceador migra los datos rango por rango. Sin embargo, no espera a que finalice la fase de eliminaci贸n de la migraci贸n actual para iniciar la siguiente migraci贸n de rango.Consulte Migraci贸n de rango para conocer el proceso de migraci贸n de rango y la fase de eliminaci贸n.
Este comportamiento de puesta en cola permite que los fragmentos descarguen datos m谩s r谩pidamente en casos de cl煤steres muy desequilibrados, como cuando se realizan cargas de datos iniciales sin divisi贸n previa y cuando se agregan nuevos fragmentos.
Este comportamiento tambi茅n afecta al moveRange comando y los scripts de migraci贸n que utilizan el moveRange comando pueden avanzar m谩s r谩pidamente.
En algunos casos, las fases de eliminaci贸n pueden persistir durante m谩s tiempo. Las migraciones de rango se han optimizado 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 servidor principal de un conjunto de r茅plicas falla o se reinicia durante esta fase.
Importante
Cuando _waitForDelete se configura el campo, MongoDB no espera el retraso antes de eliminar el rango. Si usa orphanCleanupDelaySecs el _waitForDelete par谩metro y realiza operaciones de lectura en los secundarios, es posible que la lectura omita documentos debido a la fase de eliminaci贸n de la migraci贸n.
Para m谩s informaci贸n, consulte Esperar para borrar.
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.
Migraci贸n y replicaci贸n de rangos
Durante la migraci贸n de rango, el valor _secondaryThrottle determina cu谩ndo contin煤a la migraci贸n con el siguiente documento en el rango.
En la config.settings colecci贸n:
Si la
_secondaryThrottleconfiguraci贸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
_secondaryThrottleno 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 por rangos tienen la siguiente pol铆tica de replicaci贸n:
MongoDB pausa brevemente todas las lecturas y escrituras de la aplicaci贸n en la colecci贸n migrada en el fragmento de origen antes de actualizar los servidores de configuraci贸n con la ubicaci贸n del rango. MongoDB reanuda las lecturas y escrituras de la aplicaci贸n despu茅s de la actualizaci贸n. El traslado del rango 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 rango en los servidores de configuraci贸n.
Cuando finaliza una migraci贸n 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.
Cantidad m谩xima de documentos por rango para migrar
Por defecto, MongoDB no puede mover un rango si el n煤mero de documentos en el rango es mayor que 2 veces el resultado de dividir el tama帽o del rango configurado por el tama帽o promedio de los documentos. Si MongoDB puede mover un subrango de un fragmento y reducir su tama帽o a menos de eso, el balanceador lo hace migrando un rango. db.collection.stats() incluye el campo avgObjSize, que representa el tama帽o medio de los documentos en la colecci贸n.
Para fragmentos que son demasiado grandes para migrar:
La configuraci贸n del balanceador
attemptToBalanceJumboChunkspermite que el balanceador migre fragmentos demasiado grandes para mover, siempre que los fragmentos no est茅n etiquetados como jumbo. Consulte los rangos de balance que exceden el l铆mite de tama帽o para obtener m谩s detalles.Al emitir los comandos
moveRangeymoveChunk, es posible especificar la opci贸n forceJumbo para permitir la migraci贸n de rangos que son demasiado grandes para moverse. Los rangos pueden o no estar etiquetados como jumbo.
Ajuste del rendimiento de la eliminaci贸n de rango
Puede ajustar el impacto en el rendimiento de las eliminaciones de rango con rangeDeleterBatchSize rangeDeleterBatchDelayMSy.
Por ejemplo:
Para limitar la cantidad de documentos eliminados por lote, puede establecer en un valor
rangeDeleterBatchSizepeque帽o,32como.Para agregar un retraso adicional entre eliminaciones por lotes, puede establecer por encima del
rangeDeleterBatchDelayMSvalor20predeterminado 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.
Change Streams y documentos hu茅rfanos
A partir de MongoDB,5.3 durante la migraci贸n de rango, no se generan eventos de flujode cambio para las actualizaciones de documentos hu茅rfanos.
Tama帽o del fragmento
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.
Tama帽o de los fragmentos y equilibrio
Para obtener una introducci贸n chunkSize a, consulte Modificar el tama帽o del rango en un cl煤ster fragmentado.
Cuando los datos de recopilaci贸n compartidos entre dos fragmentos difieren en tres o m谩s veces el valor configurado chunkSize, el equilibrador migra fragmentos entre los fragmentos.
Por ejemplo, si chunkSize es 128 MB y los datos de recopilaci贸n difieren en 384 MB o m谩s, el equilibrador migra fragmentos entre los fragmentos.
Cuando los fragmentos se mueven, se dividen o se fusionan, los metadatos de la partici贸n se actualizan despu茅s de que la operaci贸n de fragmento es confirmada por un servidor de configuraci贸n. Las Particiones no involucradas en la operaci贸n de fragmentos tambi茅n se actualizan con nuevos metadatos.
El tiempo de actualizaci贸n de los metadatos del fragmento es proporcional al tama帽o de la tabla de enrutamiento. Las operaciones CRUD en la colecci贸n se bloquean temporalmente mientras se actualizan los metadatos del fragmento, y una tabla de enrutamiento m谩s peque帽a implica menores retrasos en las operaciones CRUD.
Desfragmentar una colecci贸n reduce la cantidad de fragmentos y el tiempo necesario para actualizar los metadatos de cada fragmento.
Para reducir la carga de trabajo del sistema, configure el balanceador para que se ejecute solo en un horario espec铆fico mediante una ventana de balanceo de fragmentos. La desfragmentaci贸n se ejecuta durante esta ventana.
Puede utilizar el par谩metro para limitar la velocidad de los comandos de divisi贸n y fusi贸n que ejecuta el chunkDefragmentationThrottlingMS balanceador.
Puede iniciar y detener la desfragmentaci贸n en cualquier momento.
Tambi茅n puedes configurar una zona de fragmentos. Una zona de fragmentos se basa en la clave de fragmento y puedes asociar cada zona con uno o m谩s fragmentos de un cl煤ster.
Un cl煤ster fragmentado solo divide fragmentos cuando es necesario migrarlos. Esto significa que el tama帽o del fragmento puede superar chunkSize. Los fragmentos m谩s grandes reducen la cantidad de fragmentos en un fragmento y mejoran el rendimiento, ya que se reduce el tiempo de actualizaci贸n de los metadatos. Por ejemplo, podr铆a ver un fragmento de 1 TB en un fragmento aunque haya configurado chunkSize en 256 MB.
chunkSize Afecta lo siguiente:
Cantidad m谩xima de datos que el balanceador intenta migrar entre dos fragmentos en una sola operaci贸n de migraci贸n de fragmentos.
Cantidad de datos migrados durante la desfragmentaci贸n.
Para obtener detalles sobre c贸mo desfragmentar colecciones fragmentadas, consulte Desfragmentar colecciones fragmentadas.