Una lista de verificación de desarrollo y operaciones para MongoDB

Las listas de verificación de operación y desarrollo de MongoDB están destinadas a ayudar a los administradores de bases de datos a evitar problemas en el entorno de producción de MongoDB. Una lista de verificación de desarrollo debe abordar cuestiones como...

1. Diseño del esquema
2. Durabilidad de los datos
3. Replicación
4. Impulsores 
5. fragmentación 

Una lista de verificación de operaciones, por otro lado, aborda...

1. Replicación
2. Sistema de archivos 
3. fragmentación
4. Hardware
5. Diario (motor de almacenamiento WiredTiger) 
6. Configuraciones del sistema operativo 
7. Implementación en hardware en la nube 
8. Monitoreo
9. Copias de seguridad y equilibrio de carga

Antes de iniciar un proyecto, es recomendable trabajar en la lista de verificación de operación y desarrollo para permitir el buen funcionamiento de MongoDB en producción. Este artículo explica la lista de verificación de operación y desarrollo antes de implementar MongoDB.

Lista de verificación de operaciones de MongoDB

Replicación

Todos los conjuntos de miembros de réplica que no estén ocultos deben aprovisionarse de forma idéntica en cuanto a disco, RAM, configuración de red y CPU.

El tamaño de Oplog debe configurarse correctamente para abordar las necesidades operativas de manera que:

• Para evitar la necesidad de una resincronización completa, la ventana de la aplicación de réplica de oplog debe cubrir el tiempo de inactividad regular y la ventana de mantenimiento.
• Para restaurar un miembro del conjunto de replicación, la ventana de registro de operaciones de la réplica siempre debe cubrir el tiempo necesario.

El conjunto de producción debe incorporar, como mínimo, tres nodos portadores de datos que se ejecuten con el registro en diario habilitado. Además, las escrituras deben emitirse con w:preocupación de escritura "mayoritaria" con el fin de garantizar la disponibilidad y durabilidad de los datos.

La implementación debe contener un número impar de miembros con derecho a voto para facilitar el proceso de votación siempre que falle el nodo principal del clúster.

En lugar de usar direcciones IP que pueden requerir una para cambiar las configuraciones debido al cambio de IP, se recomienda el uso de nombres de host DNS lógicos.

Asegúrese de que las instancias de mongod tengan 0 o 1 votos.

Todas las instancias de Mongod deben estar conectadas completa y bidireccionalmente de modo que haya una comunicación sencilla de datos entre los nodos involucrados.

Diario

Esta es una estrategia de escritura anticipada de archivos diarios en disco que se emplea para garantizar la durabilidad de los datos en caso de falla. Todas las instancias deben tener habilitado el diario por este motivo, especialmente cuando se trata de cargas de trabajo de escritura intensiva.

Sin embargo, tenga en cuenta que esto afecta los refuerzos de estilo de instantánea, ya que los registros que constituyen el estado de la base de datos permanecerán en volúmenes particionados.

Sistema de archivos

No utilice unidades de News File System (NFS) para dbPath. Las unidades NFS posiblemente pueden resultar en un rendimiento desestabilizado. Se recomienda el uso de unidades virtuales de VMware por parte de los usuarios de VMware.

Asegúrese de que las particiones de su disco estén alineadas con sus configuraciones de RAIDON.

Para usuarios de Linux/Unix, se recomienda el uso de XFS. Se sabe que XFS funciona mejor con MongoDB.

Para los usuarios del sistema operativo Windows, se recomienda el sistema de archivos NTFS. Debe evitar el uso de cualquier sistema de archivos FAT.

Implementación en hardware en la nube

Windows Azure:modifique el keepalive de TCP (tcp_keepalive_time) a 100-120. El tiempo de espera de TCP fuera del engranaje en el equilibrador de pila de Azure también es moderado para el comportamiento de agrupación de asociaciones de MongoDB

Use MongoDB 2.6.4 o versiones más recientes en marcos con almacenamiento de alta latencia, como Windows Azure, ya que estas versiones incorporan mejoras de ejecución para esos marcos.

fragmentación

Coloque sus servidores de configuración en hardware dedicado para una ejecución ideal en clústeres expansivos.

Asegúrese de que el hardware tenga suficiente RAM para mantener los registros de información completamente en la memoria y tenga almacenamiento dedicado.

Implemente enrutadores mongos de acuerdo con las pautas de configuración de generación.

Sincronice los relojes en todos los componentes de su clúster fragmentado mediante NTP.

Asegure una red bidireccional completa entre mongos, mongod y servidores de configuración.

Utilice CNAME para reconocer sus servidores de configuración en el clúster para que pueda cambiar el nombre y volver a numerar sus servidores de configuración sin tiempo de inactividad.

Monitoreo

Puede utilizar herramientas como MongoDB Cloud Manager, ClusterControl u otro marco de monitoreo para evaluar las métricas clave de la base de datos y configurar alarmas. Incorpora alertas para las métricas:

• Colas
• Ventana de registro de replicación
• Afirmaciones
• Fallos de página
• Retraso de replicación

Supervise las métricas de hardware de sus servidores. Preste especial atención al espacio disponible en el disco, el uso del disco, la CPU

Hardware

Utilice unidades RAID10 y SSD para un rendimiento ideal.

SAN y Virtualización:

Asegúrese de que cada una de las instancias de mongod haya aprovisionado IOPS para su dbPath, o tenga su unidad física de reclamo o LUN.

Evite los aspectos destacados de la memoria dinámica, como la expansión de la memoria, cuando se ejecuta en entornos virtuales.

Evite configurar todas las personas del conjunto de copia en la misma SAN, ya que la SAN puede ser un único punto de decepción.

Equilibrio de carga

Diseñe balanceadores de carga para habilitar "sesiones persistentes" o "afinidad de cliente" con un tiempo de espera adecuado para las conexiones existentes.

Evite colocar balanceadores de carga entre el clúster MongoDB o los componentes del conjunto de réplicas.

Copias de seguridad

Planifique pruebas intermitentes de su proceso de copia de seguridad y restauración para tener indicadores de tiempo a mano y confirmar su utilidad.

Configuración del sistema operativo

Windows

Considere desactivar las actualizaciones de "hora del último acceso" de NTFS.

Formatee los discos NTFS utilizando el tamaño de unidad de asignación predeterminado de 4096 bytes.

Linux

Apague las enormes páginas transparentes.

Haga ajustes a la configuración del cabezal de lectura de los dados donde se almacenan los archivos de su base de datos. La lectura anticipada del motor de almacenamiento WiredTiger debe establecerse entre 8 y 32.

Si utiliza sintonizado en RHEL / CentOS, debe personalizar su perfil ajustado. Muchos de los perfiles optimizados que se envían con RHEL/CentOS pueden afectar negativamente la ejecución con su configuración predeterminada. Personalice su perfil sintonizado elegido para:

Deshabilitar páginas gigantes sencillas.

Establezca la lectura anticipada entre 8 y 32 en cualquier caso de clasificación de medios de capacidad.

Utilice los programadores de disco noop o de fecha límite para las unidades SSD.

Utilice el programador de disco noop para unidades virtualizadas en máquinas virtuales invitadas.

Desactive NUMA o establezca vm.zone_reclaim_mode en 0 y ejecute instancias mongod con intercalación de nodos.

Ajuste los valores de ulimit en su hardware para que coincida con su caso de uso. En el caso de que se estén ejecutando diferentes ocurrencias de mongod o mongos bajo el mismo cliente, escale los valores de ulimit de la misma manera.

Diseñe controladores de registro adecuados (fs.file-max), restricción de pid parcial (kernel.pid_max), subproceso máximo por proceso (kernel.threads-max) y número máximo de áreas de esquema de memoria por proceso (vm.max_map_count) para su envío. Para marcos expansivos, los siguientes valores brindan un excelente punto de partida:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

Asegúrese de que su marco tenga espacio de intercambio configurado.

Haga referencia a la documentación de su sistema operativo para conocer los puntos de interés sobre el tamaño correcto.

 Asegúrese de que el keepalive de TCP predeterminado del sistema esté configurado con precisión. Un valor de 300 suele ofrecer un rendimiento superior para conjuntos de réplicas y clústeres fragmentados.

Lista de verificación de desarrollo de MongoDB

Replicación

Utilice un número impar de votantes para garantizar que las elecciones continúen de manera efectiva. Tendrá hasta 7 personas con derecho a voto. En el caso de que tenga un número par de personas con derecho a voto y las restricciones, como el costo, impidan incluir a otro secundario para ser miembro con derecho a voto, podrá incluir un árbitro para garantizar un número impar de votos.

Asegúrese de que sus archivos secundarios se mantengan actualizados mediante el uso de herramientas de monitoreo y la indicación de un problema de escritura adecuado.

No utilice lecturas auxiliares para escalar el rendimiento de lectura general.

Diseño de esquema

Los datos en MongoDB contienen un patrón dinámico. Las colecciones no mantienen la estructura del informe. Esto fomenta la mejora iterativa y el polimorfismo. En cualquier caso, las colecciones suelen contener registros con estructuras excesivamente homogéneas.

Decida el conjunto de colecciones que necesitará y los índices necesarios para respaldar sus consultas. Con el caso especial del índice _id, debe crear todos los índices expresamente:MongoDB no crea naturalmente ningún índice que no sea _id.

Garantice que su plan de esquema admita su tipo de implementación:en caso de que planee utilizar clústeres fragmentados para el escalado horizontal, planifique su esquema para incorporar una clave de fragmento sólida. La clave de fragmento influye en la ejecución de lectura y escritura al decidir cómo MongoDB segmenta los datos. No puede modificar la clave de fragmento una vez configurada.

Asegúrese de que su plan de esquema no dependa de clústeres indexados que crecen sin límites. Por lo general, la mejor ejecución se puede lograr cuando dichos clústeres indexados tienen menos de 1000 componentes.

Tenga en cuenta los límites de estimación del documento al diseñar su esquema. El límite de estimación de documentos de BSON es de 16 MB por documento. En caso de que necesite informes más grandes, use GridFS.

Controladores

Utilice la agrupación de asociaciones. La mayoría de los controladores de MongoDB admiten la agrupación de asociaciones. Modifique el tamaño del grupo de asociaciones para que se adapte a su caso de uso, a partir del 110-115 % del número normal de demandas simultáneas de bases de datos.

Asegúrese de que sus aplicaciones manejen errores temporales de escritura y lectura en medio de elecciones de conjuntos de réplicas.

Garantice que sus aplicaciones manejen las solicitudes fallidas y vuelva a intentarlas si corresponde. Los conductores no

volver a intentar naturalmente las solicitudes fallidas.

Utilice la lógica de retroceso exponencial para los reintentos de solicitud de base de datos.

Utilice cursor.maxTimeMS() para lecturas y wtimeout para escrituras en caso de que desee limitar el período de ejecución de las operaciones de la base de datos.

Durabilidad de los datos

Asegúrese de que su conjunto de réplicas incorpore al menos tres centros de almacenamiento de datos con preocupación de redacción mayoritaria. Se requieren tres concentradores de datos para la solidez de los datos en todo el conjunto de réplicas.

Garantice que todas las instancias utilicen registro en diario.

fragmentación

Garantice que su clave de fragmento transmita la carga por igual en sus fragmentos.

Utilice operaciones dirigidas para cargas de trabajo que se escalaron con la cantidad de fragmentos.

Para MongoDB 3.6 y versiones posteriores, los secundarios ya no devuelven datos huérfanos a menos que utilicen la preocupación de lectura "disponible" (que es la preocupación de lectura predeterminada para lecturas contra secundarios cuando no están relacionadas con sesiones causalmente confiables).

A partir de MongoDB 3.6, todos los miembros del conjunto de réplicas de fragmentos conservan metadatos de fragmentos, lo que les permite filtrar huérfanos cuando no utilizan "disponible". Como tal, las consultas no dirigidas o de transmisión que no utilizan "disponible" se pueden ejecutar de forma segura en cualquier miembro y no devolverán información huérfana.

La preocupación de lectura "accesible" puede devolver documentos huérfanos de miembros auxiliares, ya que no verifica los metadatos de fragmentos revisados. En cualquier caso, en caso de que la devolución de documentos huérfanos sea insignificante para una aplicación, la preocupación de lectura "disponible" ofrece la menor cantidad posible de lecturas de inactividad entre las diferentes preocupaciones de lectura.

Dividir previamente y ajustar manualmente fragmentos al incorporar conjuntos de datos expansivos en una nueva colección fragmentada sin hash. La división previa y el ajuste físico permiten que la pila de incrustaciones se disperse entre los fragmentos, lo que amplía la ejecución de la carga inicial.

Conclusión 

La gestión de la lista de verificación de operaciones y desarrollo es un paso crucial que los desarrolladores deben incorporar cuando usan MongoDB en producción. Son consideraciones clave porque mejoran el flujo de tareas para un proyecto en producción. El entorno de producción de MongoDB requiere funciones de base de datos estables y confiables porque la base de datos en producción almacena datos de trabajo del mundo real. La integridad de los datos depende de la estabilidad de la base de datos que se habilita al garantizar que todos los elementos de la lista de verificación de operación y desarrollo se trabajen antes de la producción.