La implementación de MongoDB en producción solo puede funcionar realmente si se sigue el patrón de implementación correcto. La implementación de un conjunto de réplicas en un solo host no garantiza la alta disponibilidad de los datos. Tratar con big data requiere una investigación exhaustiva e implementaciones óptimas, ya sea combinando las opciones disponibles o eligiendo la que tenga los beneficios más prometedores.
Los patrones de implementación para MongoDB incluyen:
- Conjuntos de réplicas de tres miembros
- Conjuntos de réplicas distribuidos en dos o más centros de datos.
Conjuntos de réplicas de tres miembros
La replicación es una estrategia de escalado para MongoDB que mejora la alta disponibilidad de datos. Un conjunto de réplicas implica:
- Un nodo principal:responsable de todas las operaciones de rendimiento de escritura y también se puede leer.
- Nodos secundarios:solo se pueden usar para operaciones de lectura, pero se pueden elegir como primarios en caso de que falle el existente. Obtienen sus actualizaciones de datos de un registro de operaciones generado por el miembro principal del conjunto.
- Árbitro. Se utiliza para facilitar la elección de un primario en caso de que haya un número par de miembros del conjunto de réplicas. No aloja ninguna copia de los datos.
Los beneficios de un conjunto de réplicas solo se pueden obtener con un número mínimo de tres miembros con la siguiente arquitectura:
Primario-Secundario-Secundario
Este es el más recomendado ya que tiene una mayor tolerancia a fallas y aborda las limitaciones de agregar un tercer miembro que contiene datos, como el costo.
Esta implementación siempre proporcionará dos copias completas además de los datos principales, lo que garantiza una alta disponibilidad. La falla del principal activará el conjunto de réplicas para elegir un nuevo principal y la operación de servicio se reanudará con normalidad. Si el principal antiguo vuelve a estar activo, se clasificará como miembro secundario.
Durante el proceso de elección, los miembros se señalan entre sí a través de un latido y no hay operaciones de escritura durante este tiempo
Luego del proceso electoral asumimos la arquitectura a reformar como:
Árbitro primario-secundario
Esto garantiza que el conjunto de réplicas permanezca disponible incluso si el principal o el secundario no están disponibles al facilitar el proceso de elección de un secundario a un principal. Los árbitros no llevan ninguna copia de los datos, por lo que requieren menos recursos para administrar.
Una limitación de esta implementación es; sin redundancia ya que solo hay dos miembros portadores de datos:primario y secundario. Esto da como resultado una menor tolerancia a fallas.
La tolerancia a fallas debe poder garantizar:
- Disponibilidad de escritura:se necesita la mayoría de los miembros del conjunto de réplicas de votación para mantener o elegir al principal responsable de las operaciones de escritura.
- Redundancia de datos:la escritura puede ser reconocida por varios miembros para evitar reversiones
La configuración del árbitro primario-secundario admite el aspecto de disponibilidad de escritura solo de modo que si un solo miembro del conjunto no está disponible, aún se puede mantener un primario.
Sin embargo, la falta de compatibilidad con el segundo aspecto tendrá algunas consecuencias operativas si el miembro secundario deja de estar disponible:
- No habrá replicación activa, especialmente si la secundaria está desconectada por mucho tiempo. Cuando el secundario está fuera de línea durante demasiado tiempo, puede caerse del registro de operaciones, lo que obliga a resincronizarlo durante el reinicio.
- Se saboteará la redundancia de datos, lo que obligará a que la operación de escritura sea reconocida solo por el principal actual.
- La mayoría con opción de preocupación no proporcionará los datos más recientes a las aplicaciones conectadas y los procesos internos. Este es el caso cuando su configuración espera escrituras para solicitar el reconocimiento de la mayoría, por lo tanto, se bloquea hasta que la mayoría de los miembros que contienen datos estén disponibles.
- La migración de fragmentos entre fragmentos también se verá comprometida si el conjunto de réplicas forma parte de un clúster fragmentado.
- Presión en la memoria caché del motor de almacenamiento de WiredTiger si se producen reversiones y no se puede avanzar en el punto de compromiso mayoritario.
Para evitar estas consecuencias, se puede optar por una configuración Primaria-Secundaria-Secundaria ya que aumenta la tolerancia a fallas.
Nota:la tolerancia a fallas no se presenta solo en caso de falla, sino que también algunas operaciones del sistema, como la actualización de software y el mantenimiento normal, pueden obligar a un miembro a no estar disponible brevemente.
Conjuntos de réplicas distribuidos en dos o más centros de datos
La alta disponibilidad se puede elevar a otro nivel mediante la distribución de miembros del conjunto de réplicas en centros de datos geográficamente distintos. Este enfoque aumentará la redundancia además de garantizar una alta tolerancia a fallas en caso de que algún centro de datos no esté disponible.
Si todos los miembros están ubicados en un solo centro de datos, el conjunto de réplicas es susceptible de fallas en el centro de datos, como transitorios de red y cortes de energía.
Es recomendable mantener al menos un miembro en un centro de datos alternativo, use un número impar de centros de datos y seleccione una distribución de miembros que ofrezca una mayoría para la elección o, como mínimo, proporcione una copia de los datos en caso de falla.
La configuración debe garantizar que si algún centro de datos deja de funcionar, el conjunto de réplicas se puede escribir ya que los miembros restantes pueden realizar una elección.
Distribuya sus datos al menos entre tres centros de datos.
Los miembros pueden tener recursos limitados o restricciones de red, lo que los hace inadecuados para convertirse en principales en caso de conmutación por error. Puede configurar estos miembros para que no se conviertan en principales dándoles prioridad 0.
Los miembros de un centro de datos pueden tener una prioridad más alta que otros centros de datos para darles una prioridad de voto de modo que puedan elegir primarias antes que los miembros de otros centros de datos.
Todos los miembros del conjunto de réplicas deberían poder comunicarse entre sí.
Conclusión
Los beneficios de la replicación se pueden elevar a un estado más prometedor al distribuir a los miembros en varios centros de datos. Esto esencialmente aumenta la tolerancia a fallas además de garantizar la redundancia de datos. Los miembros del conjunto de réplicas, cuando se distribuyen en dos o más centros de datos, brindan beneficios sobre un único centro de datos, como:
Si uno de los centros de datos deja de funcionar, los datos aún estarán disponibles para lecturas, a diferencia de la distribución de un solo centro de datos.
Las operaciones de escritura aún se pueden reconocer cada vez que se cae un centro de datos con miembros minoritarios.
Las operaciones de lectura aún pueden ser posibles si el centro de datos con la mayoría de los miembros con derecho a voto deja de funcionar, a diferencia del caso del centro de datos único.
