replica - ¿Por qué los servidores de configuración MongoDB deben ser solo uno o tres?

sharding mongodb

Question

Después de leer la documentación oficial de la arquitectura de fragmentación MongoDB, no he descubierto por qué necesita tener uno o tres servidores de configuración, y no otro número.

La documentación de MongoDB en servidores de configuración dice:

"Si uno o dos servidores de configuración dejan de estar disponibles, los metadatos del clúster se vuelven de solo lectura. Todavía puede leer y escribir datos de los fragmentos, pero no se producirán migraciones o divisiones de fragmentos hasta que estén disponibles los tres servidores".

De ahí la reflexión: un servidor es equivalente a un único punto de falla, pero con dos servidores tenemos el mismo comportamiento que tres, ¿verdad?

Entonces, ¿por qué absolutamente tres servidores y no solo dos o más, por ejemplo?

Porque el doctor también dice:

Los servidores de configuración no se ejecutan como conjuntos de réplicas.

Answer 1

Protocolos del servidor de configuración

MongoDB 3.0 y versiones anteriores solo son compatibles con un único tipo de protocolo de implementación del servidor de configuración al que se hace referencia como SCCC heredado (Configuración de conexión de clúster de sincronización) a partir de MongoDB 3.2. Una implementación de SCCC tiene 1 servidor de configuración (solo desarrollo) o 3 servidores de configuración (producción).

MongoDB 3.2 rechaza el protocolo SCCC y admite un nuevo tipo de despliegue: Servidores de configuración como conjuntos de réplica (CSRS). Una implementación de CSRS tiene los mismos límites que un conjunto de réplicas estándar, que puede tener 1 servidor de configuración (solo desarrollo) o hasta 50 servidores (producción) como en MongoDB 3.2. Se recomienda un mínimo de 3 servidores CSRS para alta disponibilidad en una implementación de producción, pero servidores adicionales pueden ser útiles para implementaciones geográficamente distribuidas.

SCCC (configuración de conexión del clúster de sincronización)

Con SCCC, los servidores de configuración se actualizan utilizando un protocolo de confirmación en dos fases que requiere consenso de varios servidores para una transacción. Puede usar un solo servidor de configuración para fines de prueba / desarrollo, pero en el uso de producción siempre debe tener 3. Una respuesta práctica de por qué no puede usar solo 2 (o más de 3) servidores en MongoDB es que la base de código MongoDB solo admite 1 o 3 servidores de configuración para una configuración de SCCC.

Tres servidores proporcionan una mayor garantía de consistencia que dos servidores, y permite la actividad de mantenimiento (por ejemplo, copias de seguridad) en un servidor de configuración, mientras que todavía tiene dos servidores disponibles para que los mongos puedan consultar. Más de tres servidores aumentarían el tiempo requerido para confirmar datos en todos los servidores.

Los metadatos para su clúster fragmentado deben ser idénticos en todos los servidores de configuración, y se mantienen mediante la implementación de fragmentación MongoDB. Los metadatos incluyen los detalles esenciales de los fragmentos que actualmente tienen rangos de documentos (también conocidos como chunks ). En una configuración de SCCC, los servidores de configuración no son un conjunto de réplicas, por lo que si uno o más servidores de configuración están desconectados, los datos de configuración serán de solo lectura; de lo contrario, no hay forma de que los datos se propaguen a los servidores de configuración fuera de línea cuando son de nuevo en línea.

Claramente, 1 servidor de configuración no proporciona redundancia o respaldo. Con 2 servidores de configuración, un posible escenario de falla es cuando los servidores están disponibles pero los datos en los servidores no concuerdan (por ejemplo, uno de los servidores tenía daños en algunos datos). Con 3 servidores de configuración puede mejorar el escenario anterior: 2/3 servidores pueden ser consistentes y puede identificar el servidor impar.

CSRS (servidores de configuración como conjuntos de réplica)

MongoDB 3.2 desaprueba el uso de tres instancias de mongod duplicadas para servidores de configuración, y a partir de 3.2 servidores de configuración se implementan (por defecto) como un conjunto de réplicas. Los servidores de configuración de conjuntos de réplicas deben usar el motor de almacenamiento WiredTiger 3.2+ (u otro motor de almacenamiento que admita la nueva semántica de aislamiento de lectura readConcern ). CSRS también deshabilita algunas opciones de configuración de conjuntos de réplicas no predeterminadas (por ejemplo, buildIndexes , slaveDelay y slaveDelay ) que no son adecuados para el caso de uso de metadatos de clúster fragmentado.

El despliegue de CSRS mejora la coherencia y la disponibilidad para los servidores de configuración, ya que MongoDB puede aprovechar los protocolos de lectura y escritura del conjunto de réplicas estándar para fragmentar los datos de configuración. Además, esto permite que un clúster fragmentado tenga más de 3 servidores de configuración, ya que un conjunto de réplicas puede tener hasta 50 miembros (como en MongoDB 3.2).

Con una implementación de CSRS, la disponibilidad de escritura depende de mantener un quórum de miembros que puedan ver el primario actual para un conjunto de réplicas. Por ejemplo, un conjunto de réplicas de 3 nodos requeriría 2 miembros disponibles para mantener un primario. Se pueden agregar miembros adicionales para mejorar la tolerancia a fallas , sujeto a las mismas reglas de elección que un conjunto de réplicas normales. Los mongos utilizan readConcern de la majority para garantizar que los metadatos del clúster fragmentado solo puedan leerse una vez que se haya comprometido con la mayoría de los miembros del conjunto de réplicas y se readPreference una readPreference de readPreference nearest para enrutar las solicitudes al servidor de configuración más cercano.