Nuestra última versión de ClusterControl convierte algunas de las tareas más problemáticas de MongoDB en un trabajo de solo 15 segundos. Se agregaron nuevas funciones para darle más control sobre su clúster y realizar cambios de topología:
- Convertir un conjunto de réplicas de MongoDB en un clúster de MongoDB fragmentado
- Añadir y eliminar fragmentos
- Agregue enrutadores fragmentados a un clúster fragmentado de MongoDB
- Reducir o congelar un nodo
- Nuevos asesores de MongoDB
Describiremos estas funciones adicionales en profundidad a continuación.
Convertir un MongoDB ReplicaSet en un clúster de MongoDB fragmentado
Como la mayoría de los usuarios de MongoDB comenzarán con un replicaSet para almacenar su base de datos, este es el tipo de clúster más utilizado. Si tiene problemas de escalado, puede escalar este conjunto de réplicas agregando más elementos secundarios o escalando mediante fragmentación. Puede convertir un replicaSet existente en un clúster fragmentado; sin embargo, este es un proceso largo en el que podría cometer errores fácilmente. En ClusterControl, hemos automatizado este proceso, donde agregamos automáticamente los servidores de configuración, los enrutadores fragmentados y habilitamos la fragmentación.
Para convertir un replicaSet en un clúster fragmentado, simplemente puede activarlo a través del menú desplegable de acciones:
Esto abrirá un diálogo de dos pasos sobre cómo convertir esto en un fragmento. El primer paso es definir dónde implementar el servidor de configuración y los enrutadores de fragmentos:
El segundo paso es dónde almacenar los datos y qué archivos de configuración deben usarse para el servidor de configuración y el enrutador de fragmentos.
Una vez que finaliza el trabajo de migración de fragmentos, la descripción general del clúster ahora muestra fragmentos en lugar de instancias de replicaSet:
Después de convertir a un clúster fragmentado, se pueden agregar nuevos fragmentos.
Agregar o eliminar fragmentos de un clúster fragmentado de MongoDB
Agregar fragmentos
Dado que un fragmento de MongoDB es técnicamente un conjunto de réplicas, agregar un nuevo fragmento también implica la implementación de un nuevo conjunto de réplicas. Dentro de ClusterControl, primero implementamos un nuevo replicaSet y luego lo agregamos al clúster fragmentado.
Desde la interfaz de usuario de ClusterControl, puede agregar fácilmente nuevos fragmentos con un asistente de dos pasos, que se abre desde el menú desplegable de acciones:
Aquí puede definir la topología del nuevo fragmento.
Una vez que se haya agregado el nuevo fragmento al clúster, el enrutador de fragmentos de MongoDB comenzará a asignarle nuevos fragmentos y el equilibrador equilibrará automáticamente todos los fragmentos sobre todos los fragmentos.
Eliminar fragmentos
Eliminar fragmentos es un poco más difícil que agregar un fragmento, ya que esto implica mover los datos a los otros fragmentos antes de eliminar el propio fragmento. Para todos los datos que se han fragmentado en todos los fragmentos, este será un trabajo realizado por el balanceador de MongoDB.
Sin embargo, cualquier base de datos/colección que no esté fragmentada, a la que se asignó este fragmento como su fragmento principal, debe moverse a otro fragmento y convertirse en su nuevo fragmento principal. Para este proceso, MongoDB necesita saber a dónde mover estas bases de datos/colecciones no fragmentadas.
En ClusterControl, simplemente puede eliminarlos a través del menú desplegable de acciones:
Esto le permitirá seleccionar el fragmento que desea eliminar y el fragmento al que desea migrar cualquier base de datos principal:
El trabajo que elimina el fragmento realizará acciones similares a las descritas anteriormente:moverá las bases de datos principales al fragmento designado, habilitará el balanceador y luego esperará a que mueva todos los datos del fragmento.
Una vez que se hayan eliminado todos los datos, se eliminará el fragmento de la interfaz de usuario.
Agregar enrutadores de fragmentos MongoDB adicionales
Una vez que comience a escalar su aplicación utilizando un clúster fragmentado de MongoDB, es posible que necesite enrutadores fragmentados adicionales.
Agregar enrutadores de fragmentos MongoDB adicionales es un proceso muy simple con ClusterControl, simplemente abra el cuadro de diálogo Agregar nodo desde el menú desplegable de acciones:
Esto agregará un nuevo enrutador de fragmentos al clúster. No olvide configurar el puerto predeterminado adecuado (27017) en el enrutador.
Servidor reductor
En caso de que desee realizar tareas de mantenimiento en el nodo principal de un conjunto de réplicas, es mejor que primero lo "reduzca" de manera elegante antes de desconectarlo. Bajar un primario básicamente significa que el host deja de ser primario y se convierte en secundario y no es elegible para convertirse en primario por un número determinado de segundos. Los nodos en MongoDB replicaSet con poder de voto elegirán una nueva primaria con la primaria reducida excluida por el número establecido de segundos.
En ClusterControl, hemos agregado la funcionalidad de reducción como una acción en la página Nodos. Para bajar, simplemente seleccione esto como una acción del menú desplegable:
Después de establecer la cantidad de segundos para la reducción y la confirmación, el principal se retirará y se elegirá un nuevo principal.
Congelar un nodo
Esta funcionalidad es similar al comando de disminución:esto hace que cierto nodo no sea elegible para convertirse en principal durante un número determinado de segundos. Esto significa que puede evitar que uno o más nodos secundarios se conviertan en primarios al reducir el primario y obligar a un determinado nodo a convertirse en el nuevo primario de esta manera.
En ClusterControl, hemos agregado la función de congelación de nodos como una acción en la página Nodos. Para congelar un nodo, simplemente seleccione esto como una acción del menú desplegable:
Después de establecer la cantidad de segundos y confirmar, el nodo no será elegible como principal para la cantidad de segundos establecida.
Nuevos asesores de MongoDB
Los asesores son miniprogramas que brindan asesoramiento sobre problemas específicos de la base de datos. Hemos agregado tres nuevos asesores para MongoDB. El primero calcula la ventana de replicación, el segundo vigila la ventana de replicación y el tercero verifica las bases de datos/colecciones no fragmentadas.
Asesor de retraso de replicación de MongoDB
Es muy importante vigilar el retraso de la replicación, si está ampliando las lecturas mediante la adición de más secundarios. MongoDB solo usará estos secundarios si no se quedan demasiado atrás. Si el secundario tiene un retraso en la replicación, corre el riesgo de entregar datos obsoletos que ya se sobrescribieron en el principal.
Para verificar el retraso de la replicación, basta con conectarse al principal y recuperar estos datos mediante el comando replSetGetStatus. Al contrario de MySQL, el principal realiza un seguimiento del estado de replicación de sus secundarios.
Hemos implementado esta verificación en un asesor en ClusterControl, para garantizar que su retraso de replicación siempre esté vigilado.
Asesor de ventana de replicación de MongoDB
Al igual que el retraso de la replicación, la ventana de replicación es una métrica igualmente importante a tener en cuenta. El asesor de retraso ya nos informa la cantidad de segundos que un nodo secundario está detrás del principal/maestro. Como el oplog tiene un tamaño limitado, tener un retraso esclavo impone los siguientes riesgos:
- Si un nodo se retrasa demasiado, es posible que ya no pueda ponerse al día, ya que las transacciones necesarias para ponerse al día ya no están en el registro de operaciones del principal.
- Un nodo secundario atrasado es menos favorecido en una elección de MongoDB para un nuevo primario. Si todos los secundarios se retrasan en la replicación, tendrá un problema y uno con el menor retraso se convertirá en principal.
- Los secundarios que se quedan atrás son menos favorecidos por el controlador MongoDB al escalar las lecturas con MongoDB, también agrega una mayor carga de trabajo en los secundarios restantes.
Si tuviéramos un nodo secundario retrasado unos minutos (u horas), sería útil tener un asesor que nos informe cuánto tiempo nos queda antes de que nuestra próxima transacción se elimine del registro de operaciones. La diferencia de tiempo entre la primera y la última entrada en el registro de operaciones se denomina ventana de replicación. Esta métrica se puede crear obteniendo el primer y el último elemento del registro de operaciones y calculando la diferencia de sus marcas de tiempo.
En el shell de MongoDB, ya hay una función disponible que calcula la ventana de replicación por usted. Sin embargo, esta función está integrada en el shell de la línea de comandos, por lo que cualquier conexión externa que no utilice el shell de la línea de comandos no tendrá esta función integrada. Por lo tanto, hemos creado un asesor que vigilará la ventana de replicación y le avisará si supera un umbral preestablecido.
Asesor de colecciones y bases de datos sin fragmentos de MongoDB
El enrutador de fragmentos MongoDB asignará las bases de datos y las colecciones no fragmentadas a un fragmento principal predeterminado. Esto significa que la base de datos o la colección están limitadas al tamaño de este fragmento principal y, si se escriben en grandes volúmenes, podrían consumir todo el espacio restante en disco de un fragmento. Una vez que esto suceda, el fragmento obviamente ya no funcionará. Por lo tanto, es importante vigilar todas las bases de datos y colecciones existentes, y escanear la base de datos de configuración para validar que se hayan habilitado para la fragmentación.
Para evitar que esto suceda, hemos creado una base de datos sin fragmentar y un asesor de recopilación. Este asesor escaneará cada base de datos y colección, y le avisará si no se ha fragmentado.
ClusterControl mejoró la mantenibilidad de MongoDB
Hemos dado un gran paso al agregar todas las mejoras a ClusterControl para MongoDB replicaSets y clústeres fragmentados. ¡Esto mejora enormemente la usabilidad de MongoDB y permite que los DBA, sysops y devops mantengan sus clústeres aún mejor!
