Protocoles du serveur de configuration
MongoDB 3.0 et les versions antérieures ne prennent en charge qu'un seul type de protocole de déploiement de serveur de configuration, appelé SCCC hérité (Sync Cluster Connection Configuration) à partir de MongoDB 3.2. Un déploiement SCCC a soit 1 serveur de configuration (développement uniquement) soit 3 serveurs de configuration (production).
MongoDB 3.2 déprécie le protocole SCCC et prend en charge un nouveau type de déploiement :Config Servers as Replica Sets (CSRS). Un déploiement CSRS a les mêmes limites qu'un jeu de répliques standard, qui peut avoir 1 serveur de configuration (développement uniquement) ou jusqu'à 50 serveurs (production) comme dans MongoDB 3.2. Un minimum de 3 serveurs CSRS est recommandé pour une haute disponibilité dans un déploiement de production, mais des serveurs supplémentaires peuvent être utiles pour les déploiements géographiquement distribués.
SCCC (configuration de la connexion du cluster de synchronisation)
Avec SCCC, les serveurs de configuration sont mis à jour à l'aide d'un validation en deux phases protocole qui nécessite le consensus de plusieurs serveurs pour une transaction. Vous pouvez utiliser un seul serveur de configuration à des fins de test/développement, mais en utilisation de production, vous devriez toujours en avoir 3. Une réponse pratique pour expliquer pourquoi vous ne pouvez pas utiliser seulement 2 (ou plus de 3) serveurs dans MongoDB est que la base de code MongoDB seulement prend en charge 1 ou 3 serveurs de configuration pour une configuration SCCC.
Trois serveurs offrent une meilleure garantie de cohérence que deux serveurs et permettent une activité de maintenance (par exemple, des sauvegardes) sur un serveur de configuration tout en ayant deux serveurs disponibles pour vos mongos interroger. Plus de trois serveurs augmenteraient le temps nécessaire pour valider les données sur tous les serveurs.
Les métadonnées de votre cluster partitionné doivent être identiques sur tous les serveurs de configuration et sont conservées par l'implémentation de partitionnement MongoDB. Les métadonnées incluent les détails essentiels dont les fragments contiennent actuellement des plages de documents (alias chunks ). Dans une configuration SCCC, les serveurs de configuration ne sont pas un jeu de réplicas, donc si un ou plusieurs serveurs de configuration sont hors ligne, les données de configuration seront en lecture seule. Sinon, les données n'ont aucun moyen de se propager aux serveurs de configuration hors ligne lorsqu'ils sont de nouveau en ligne.
Clairement 1 serveur de configuration ne fournit aucune redondance ou sauvegarde. Avec 2 serveurs de configuration, un scénario d'échec potentiel est celui où les serveurs sont disponibles mais les données sur les serveurs ne concordent pas (par exemple, l'un des serveurs a des données corrompues). Avec 3 serveurs de configuration, vous pouvez améliorer le scénario précédent :2/3 des serveurs peuvent être cohérents et vous pouvez identifier le serveur impair.
CSRS (serveurs de configuration en tant qu'ensembles de répliques)
MongoDB 3.2 déconseille l'utilisation de trois mongod en miroir les instances pour les serveurs de configuration et à partir de la version 3.2, les serveurs de configuration sont (par défaut) déployés en tant que jeu de répliques. Les serveurs de configuration de jeu de répliques doivent utiliser le moteur de stockage WiredTiger 3.2+ (ou un autre moteur de stockage prenant en charge le nouveau readConcern
lire la sémantique d'isolement). CSRS interdit également certaines options de configuration de jeu de réplicas autres que celles par défaut (par exemple, arbiterOnly , buildIndexes , et slaveDelay ) qui ne conviennent pas au cas d'utilisation des métadonnées de cluster partitionnées.
Le déploiement CSRS améliore la cohérence et la disponibilité des serveurs de configuration, car MongoDB peut tirer parti des protocoles de lecture et d'écriture des jeux de réplicas standard pour le partage des données de configuration. De plus, cela permet à un cluster fragmenté d'avoir plus de 3 serveurs de configuration puisqu'un jeu de répliques peut avoir jusqu'à 50 membres (comme dans MongoDB 3.2).
Avec un déploiement CSRS, la disponibilité en écriture dépend du maintien d'un quorum de membres qui peuvent voir le primaire actuel pour un jeu de réplicas. Par exemple, un jeu de réplicas à 3 nœuds nécessiterait 2 membres disponibles pour maintenir un nœud principal. Des membres supplémentaires peuvent être ajoutés pour améliorer la tolérance aux pannes , soumis aux mêmes règles électorales
comme un jeu de répliques normal. Un readConcern de majority est utilisé par mongos pour s'assurer que les métadonnées du cluster partitionné ne peuvent être lues qu'une fois qu'elles sont validées pour une majorité de membres du jeu de réplicas et une readPreference du nearest est utilisé pour acheminer les requêtes vers le serveur de configuration le plus proche.
