Protocolos del servidor de configuración
MongoDB 3.0 y versiones anteriores solo admiten un único tipo de protocolo de implementación del servidor de configuración que se conoce 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 deja en desuso el protocolo SCCC y admite un nuevo tipo de implementación:Servidores de configuración como conjuntos de réplicas (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 una alta disponibilidad en una implementación de producción, pero los servidores adicionales pueden ser útiles para implementaciones distribuidas geográficamente.
SCCC (Configuración de conexión de clúster de sincronización)
Con SCCC, los servidores de configuración se actualizan mediante un compromiso de dos fases
protocolo que requiere el consenso de múltiples 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 el código base de MongoDB
Tres servidores brindan una mayor garantía de consistencia que dos servidores y permiten la actividad de mantenimiento (por ejemplo, copias de seguridad) en un servidor de configuración mientras aún tiene dos servidores disponibles para sus mongos para consultar. Más de tres servidores aumentarían el tiempo necesario para confirmar datos en todos los servidores.
Los metadatos de su clúster fragmentado deben ser idénticos en todos los servidores de configuración y la implementación de fragmentación de MongoDB los mantiene. Los metadatos incluyen los detalles esenciales de qué fragmentos contienen actualmente rangos de documentos (también conocidos como chunks ). En una configuración SCCC, los servidores de configuración no un conjunto de réplicas, por lo que si uno o más servidores de configuración están fuera de línea, 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 vuelvan a estar en línea.
Claramente, 1 servidor de configuración no proporciona redundancia ni respaldo. Con 2 servidores de configuración, un escenario de falla potencial es donde los servidores están disponibles pero los datos en los servidores no concuerdan (por ejemplo, uno de los servidores tenía algunos datos dañados). 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éplicas)
MongoDB 3.2 desaprueba el uso de tres mongod reflejados instancias para servidores de configuración y, a partir de 3.2, los servidores de configuración se implementan (de forma predeterminada) como un conjunto de réplicas. Los servidores de configuración del conjunto de réplicas deben usar el motor de almacenamiento WiredTiger 3.2+ (u otro motor de almacenamiento que admita el nuevo readConcern
leer semántica de aislamiento). CSRS también no permite algunas opciones de configuración de conjuntos de réplicas no predeterminadas (por ejemplo, arbiterOnly , buildIndexes y slaveDelay ) que no son adecuados para el caso de uso de metadatos de clúster fragmentados.
La implementación de CSRS mejora la coherencia y la disponibilidad de 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 principal 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 principal. Se pueden agregar miembros adicionales para mejorar la tolerancia a fallas , sujeto a las mismas reglas electorales
como un juego de réplica normal. Una readConcern de majority es usado por mongos para garantizar que los metadatos del clúster fragmentado solo se puedan leer una vez que se hayan confirmado para la mayoría de los miembros del conjunto de réplicas y una readPreference de nearest se utiliza para enrutar solicitudes al servidor de configuración más cercano.
