Consideraciones para administrar MongoDB

A continuación se muestra un extracto de nuestro documento técnico "Gestión y automatización de MongoDB con ClusterControl" que se puede descargar de forma gratuita.

Consideraciones para administrar MongoDB

Redundancia integrada

Una característica clave de MongoDB es su redundancia integrada, en forma de replicación. Si tiene dos o más nodos de datos, se pueden configurar como un conjunto de réplicas, en el que todos los datos escritos en el nodo principal se replican casi en tiempo real en los nodos secundarios,

asegurando múltiples copias de los datos. En el caso de la conmutación por error principal, los nodos restantes en el conjunto de réplicas realizan una elección y promueven al ganador como principal, un proceso que generalmente demora de 2 a 3 segundos, y se pueden reanudar las escrituras en el conjunto de réplicas. MongoDB también usa un diario para escrituras más rápidas y seguras en el servidor o conjunto de réplicas, y también emplea un método de "preocupación de escritura" a través del cual se
configura el nivel de redundancia de escritura.

Para implementar manualmente un conjunto de réplicas, los pasos generales son los siguientes:

1. Asigne un único host físico o virtual para cada nodo de la base de datos e instale el cliente de línea de comandos de MongoDB en su escritorio. Para una configuración de conjunto de réplicas redundantes, se requiere un mínimo de tres nodos, al menos dos de los cuales serán nodos de datos. Un nodo en el conjunto de réplicas puede configurarse como árbitro:este es un proceso mongod configurado solo para formar un quórum proporcionando un voto en la elección de una Primaria cuando sea necesario. Los datos no se replican en los procesos de árbitro.
2. Instale MongoDB en cada nodo. Algunas distribuciones de Linux incluyen MongoDB Community Edition, pero tenga en cuenta que es posible que no incluyan las últimas versiones. MongoDB Enterprise solo está disponible mediante descarga desde el sitio web de MongoDB. Una funcionalidad similar a MongoDB Enterprise también está disponible a través de Percona Server para MongoDB, un reemplazo directo para MongoDB Enterprise o Community Edition.
3. Configure los archivos de configuración mongod.conf individuales para su conjunto de réplicas, utilizando el "parámetro de replicación". Si va a utilizar un archivo de clave para la seguridad, configúrelo ahora también. Tenga en cuenta que el uso de la seguridad del archivo de claves también permite la autenticación basada en roles, por lo que también deberá agregar usuarios y roles para usar los servidores. Reinicie el proceso mongod en cada servidor.
4. Asegure la conectividad entre los nodos. Debe asegurarse de que los nodos del conjunto de réplicas de MongoDB puedan comunicarse entre sí en el puerto 27017, y también que sus clientes puedan conectarse a cada uno de los nodos del conjunto de réplicas en el mismo puerto.
5. Con el cliente de línea de comandos de MongoDB, conéctese a uno de los servidores y ejecute rs.initiate() para inicializar su conjunto de réplicas, seguido de rs.add() para cada nodo adicional. Se puede usar rs.conf() para ver la configuración.

Si bien estos pasos no son tan complejos como implementar y configurar un clúster fragmentado de MongoDB o fragmentar una base de datos relacional, pueden ser onerosos y propensos a errores, especialmente en entornos más grandes.

Escalabilidad

MongoDB se conoce con frecuencia como software de base de datos de "escala web", debido a su capacidad para escalar horizontalmente. Al igual que las bases de datos relacionales, es posible escalar MongoDB verticalmente, simplemente actualizando el host físico en el que reside con más núcleos de CPU, más RAM, discos más rápidos o incluso una mayor velocidad de bus. Sin embargo, la escala vertical tiene sus límites, tanto en términos de relación costo-beneficio y rendimientos decrecientes, como de limitación técnica. Para abordar esto, MongoDB tiene una función de "fragmentación automática", que permite que las bases de datos se dividan en muchos hosts (o conjuntos de réplicas, por redundancia). Si bien la fragmentación también es posible en plataformas relacionales, a menos que se diseñe para el inicio de la base de datos, esto requiere un rediseño importante del esquema y la aplicación, así como un rediseño de la aplicación del cliente, lo que hace que este sea un proceso tedioso, lento y propenso a errores.

La fragmentación de MongoDB funciona mediante la introducción de un proceso de enrutador, a través del cual los clientes se conectan al clúster fragmentado y los servidores de configuración, que almacenan los metadatos del clúster, la ubicación en el clúster de cada documento. Cuando un cliente envía una consulta al proceso del enrutador, primero se refiere a los servidores de configuración para obtener las ubicaciones de los documentos y luego obtiene los resultados de la consulta directamente de los servidores individuales o
conjuntos de réplicas (fragmentos). La fragmentación se lleva a cabo por colección.

Un parámetro de importancia crítica aquí, para fines de rendimiento, es la "clave de partición", un campo indexado o campo compuesto que existe en cada documento de una colección. Esto es lo que define la distribución de escritura en fragmentos de una colección. Como tal, una clave fragmentada mal elegida puede tener un efecto muy perjudicial en el rendimiento. Por ejemplo, una clave de fragmento basada puramente en series de tiempo puede dar como resultado que todas las escrituras vayan a un solo nodo durante largos períodos de tiempo. Sin embargo, una clave de fragmento con hash, aunque distribuye escrituras uniformemente entre fragmentos, puede afectar el rendimiento de lectura ya que un conjunto de resultados se recupera de muchos nodos.

Árbitros

Un árbitro MongoDB es un proceso mongod que se ha configurado para no actuar como un nodo de datos, sino para proporcionar solo la función de votar cuando se va a elegir un conjunto de réplicas Primario, para romper los empates y protegerse contra un voto dividido. Un árbitro no puede convertirse en principal, ya que no tiene una copia de los datos ni acepta escrituras. Si bien es posible tener más de un árbitro en un conjunto de réplicas, generalmente no se recomienda.

Miembros del conjunto de réplicas retrasadas

Los miembros del conjunto de réplicas retrasadas agregan un nivel adicional de redundancia, manteniendo un estado que está un número fijo de segundos detrás del principal. Dado que los miembros retrasados ​​son una "copia de seguridad continua" o una instantánea "histórica" ​​en ejecución del conjunto de datos, pueden ayudar a recuperarse de varios tipos de errores humanos.

Los miembros retrasados ​​son miembros del conjunto de réplicas "ocultos", invisibles para las aplicaciones cliente y, por lo tanto, no se pueden consultar directamente. Es posible que tampoco se conviertan en principales durante las operaciones normales y deben reconfigurarse manualmente en caso de que se vayan a utilizar para recuperarse de un error.

Copias de seguridad

La copia de seguridad de un conjunto de réplicas o un clúster fragmentado se realiza a través de la utilidad de línea de comandos "mongodump". Cuando se usa con el parámetro --oplog, esto crea un volcado de la base de datos que incluye un registro de operaciones, para crear una instantánea de un punto en el tiempo del estado de una instancia de mongod. Usando mongorestore con el parámetro --replayOplog, puede restaurar completamente el estado de los datos en el momento en que se completó la copia de seguridad, evitando inconsistencias.

Para requisitos de copia de seguridad más avanzados, hay disponible una herramienta de terceros llamada "mongodbconsistent-backup", también basada en la línea de comandos, que proporciona copias de seguridad totalmente coherentes de clústeres fragmentados, un procedimiento complejo, dado que las bases de datos fragmentadas se distribuyen en varios hosts.

Monitoreo

Hay una serie de herramientas comerciales, tanto oficiales como no oficiales, disponibles en el mercado para monitorear MongoDB. Estas herramientas, en general, son utilidades de administración de un solo producto, centrándose exclusivamente en MongoDB. Muchos se centran solo en ciertos aspectos específicos, como la gestión de colecciones en una arquitectura MongoDB existente, o en las copias de seguridad o en la implementación. Sin una planificación adecuada, esto puede conducir a una situación en la que se debe implementar y administrar una proliferación de herramientas adicionales en su entorno.

Las herramientas de línea de comandos proporcionadas con MongoDB, "mongotop" y "mongostat" pueden proporcionar una vista detallada del rendimiento de sus entornos y pueden usarse para diagnosticar problemas. Además, el cliente de línea de comandos "mongo" de MongoDB también puede ejecutar "rs.status()" - o en un clúster fragmentado "sh.status() - para ver el estado de conjuntos de réplicas o clústeres y sus hosts miembros. El comando "db.stats()" devuelve un documento que aborda el uso del almacenamiento y los volúmenes de datos, y sus equivalentes para colecciones, así como otras llamadas para acceder a muchas métricas internas.

Sinopsis

Esta ha sido una breve sinopsis de las consideraciones para administrar MongoDB. Sin embargo, incluso a un nivel tan alto, debería ser obvio de inmediato que, si bien es posible administrar un conjunto de réplicas o un clúster fragmentado desde la línea de comandos utilizando las herramientas disponibles, esto no escala en un entorno con muchos conjuntos de réplicas o con una gran producción. clúster fragmentado. En entornos medianos a grandes que comprenden muchos hosts
y bases de datos, rápidamente se vuelve inviable administrar todo con herramientas de línea de comandos y scripts. Si bien se pueden desarrollar herramientas y scripts internos para implementar y mantener el entorno, esto agrega la carga de administrar nuevos procesos y sistemas de control de revisión y desarrollo. Una simple actualización de un servidor de base de datos puede convertirse en un proceso complejo si se requieren cambios en las herramientas para admitir nuevas versiones de servidor de base de datos.

Pero sin herramientas y scripts internos, ¿cómo automatizamos y administramos los clústeres de MongoDB? ¡Descargue el documento técnico para aprender cómo hacerlo!