FAQ MongoDBConsultez toutes les FAQ

Cette section répond aux questions courantes sur la réplication de la base de données MongoDB.

Si vous ne trouvez pas la réponse que vous recherchez, consultez la liste complète des FAQ ou postez votre question dans la liste de diffusion des utilisateurs MongoDB.

MongoDB supporte des réplications maître-esclave et une variété de celle-ci, connue sous le nom de replica set. Les replica set sont la technologie de réplication conseillée.

Les nœuds principal et maître sont des nœuds qui acceptent des écritures. La réplication de MongoDB est « maître-unique » : un seul nœud peut accepter des opérations d'écriture à un moment donné.

Dans un replica set, si le nœud primary courant échoue ou devient inaccessible, les autres membres peuvent élire de façon autonome un d'entre eux comme nouveau primary.

Par défaut, les clients envoient toutes les lectures au primary ; cependant, la préférence de lecture est configurable au niveau client sur base par connexion, ce qui offre la possibilité d'envoyer les lectures plutôt aux nœuds secondary.

Les nœuds secondaire et esclave sont des nœuds en lecture seule, répliques à partir du principal.

La réplication fonctionne par l'intermédiaire d'un oplog, à partir duquel les membres secondaires/esclaves appliquent de nouvelles opérations sur eux-mêmes. Ce processus de réplication est asynchrone, donc les nœuds secondaires/esclaves peuvent ne pas toujours refléter la dernière écriture dans le principal. Mais généralement, l'écart entre les nœuds principal et secondaire est de seulement quelques millisecondes dans le cas d'une connexion sur le réseau local.

Cela varie, mais un replica set sélectionnera un nouveau primary endéans une minute.

Cela peut prendre 10-30 secondes aux membres d'un replica set pour déclarer un principal inaccessible. Cela déclenche une élection. Lors de l'élection, le cluster est indisponible pour écritures.

L'élection elle-même peut prendre encore 10-30 secondes.

	Les lectures finalement cohérentes, comme celles qui seront retournées par un replica set ne sont possibles que dans un write concern qui permet des lectures à partir des membres secondaires.

Oui.

Par exemple, un déploiement peut garder un principal et un secondaire dans un data center situé sur la côte Est des États-Unis, ainsi qu'un membre secondaire pour recouvrement après panne dans un data center sur la côte Ouest.

Voir aussi : Déployer un replica set redondant géographiquement.

Oui, mais pas sans échec de connexion et avec un temps de latence évident.

Les membres de l'ensemble vont tenter de se reconnecter aux autres membres de l'ensemble en réponse à la lenteur du réseau. Cela ne nécessite pas l'intervention de l'administrateur. Toutefois, si les connexions réseau entre les nœuds du replica set sont très lentes, il ne sera pas possible aux membres du nœud de garder la réplication.

Si la connexion TCP entre les secondaires et les instances primary est interrompue, un replica set élira automatiquement comme primaryl'un des membres secondary de l'ensemble.

Modifié dans la version 3.0.0 : Dans MongoDB 3.0.0, les replica set peuvent avoir jusqu'à 50 nœuds. Les versions précédentes ont limité à 12 le nombre maximum de membres des replica set.

Les replica set sont le mécanisme de réplication préféré dans MongoDB. Cependant, si votre déploiement nécessite plus de 50 nœuds, vous devez utiliser la réplication maître/esclave.

Dépréciée depuis la version 1.6.

Les replica set ont remplacé les replica pairs dans la version 1.6. Les replica set sont le mécanisme de réplication préféré dans MongoDB.

La journalisation facilite la récupération plus rapide après panne. Avant la journalisation, les pannes nécessitaient souvent des réparations de base de données ou resynchronisation complète de données. Les deux opérations étaient lentes, et la première était peu fiable.

La journalisation est particulièrement utile pour la protection contre les pannes de courant, surtout si votre replica set réside dans un seul de centre de données ou circuit d'alimentation.

Quand un replica set fonctionne avec la journalisation, les instances mongod peuvent redémarrer en toute sécurité sans aucune intervention de l'administrateur.

	La journalisation nécessite une certaine surcharge de ressources pour les opérations d'écriture. La journalisation n'a aucun effet sur les performances de lecture, cependant. La journalisation est activée par défaut sur toutes les versions 64 bits de MongoDB v2.0 ou supérieure.

Oui.

Toutefois, si vous voulez une confirmation qu'une écriture donnée est arrivée sur le serveur, utilisez write concern.

Après le changement du write concern par défaut, celui-ci reconnaît toutes les opérations d'écriture et les écritures non acquittées doivent être explicitement configurées. Voir la documentation Pilotes et bibliothèques client MongoDB de votre pilote pour plus d'informations.

Changé dans la version 2.6 : le shell mongo utilise maintenant par défaut les écritures sûres. Voir Les acquittements des méthodes d'écriture pour plus d'informations.

Un nouveau protocole pour les opérations d'écriture intègre write concerns à celles-ci. Les versions précédentes émettaient une commande getLastError après une écriture, afin de spécifier un write concern.

Certaines configurations ne nécessitent aucune instance d' arbitre. Les arbitres votent aux élections des primary, mais ils ne répliquent pas les données comme les membres secondaires.

Les replica set requièrent une majorité des nœuds restants pour élire un primary. Les arbitres vous permettent de construire cette majorité sans la surcharge de l'ajout de nœuds de réplication au système.

Il existe de nombreuses architectures possibles des replica set.

Un replica set ayant un nombre impair de nœuds de vote n'a pas besoin d'un arbitre.

Une configuration commune est constituée de deux nœuds de réplication qui incluent un principal et un secondary, ainsi qu'un arbitre comme troisième nœuds. Cette configuration permet à l'ensemble d'élire un principal en cas de défaillance, sans nécessiter trois nœuds de réplication.

Vous pouvez également envisager d'ajouter un arbitre à un ensemble s'il a un nombre égal de nœuds dans deux installations et des partitions de réseau sont possibles entre les installations. Dans ces cas, l'arbitre va rompre le lien entre les deux installations et permettra à l'ensemble d'élire un nouveau principal.

Voir aussi: Architectures de déploiement des replica set.

Les arbitres ne reçoivent jamais le contenu d'une collection, mais échangent les données suivantes avec le reste du replica set :

• identifiants utilisés pour authentifier l'arbitre auprès du replica set. Tous les processus MongoDB au sein d'un replica set utilisent keyfiles. Ces échanges sont cryptés ;
• données de configuration et de vote du replica set. Ces informations ne sont pas cryptées. Seuls les échanges d'informations d'identification sont cryptés.
  

Tous les membres d'un replica set, à moins que la valeur de votes soit égale à 0, votent lors des élections. Cela comprend tous les membres delayed, hidden et secondary-only. Les arbitres votent toujours aux élections et ont toujours 1 vote.

En outre, le state des membres votants détermine également si le membre peut voter. Seuls les membres avec droit de vote dans les états suivants sont éligibles pour voter :

• PRIMARY
• SECONDARY
• RECOVERING
• ARBITER
• ROLLBACK

Les membres hidden des replica set votent aux élections. Pour empêcher un membre de voter à une élection, modifiez la valeur de la configuration votes du membre à 0.

Voir aussi : Élections replica set.

Oui.

Des facteurs incluant : différentes tailles d'oplog, différents niveaux de fragmentation de stockage et la préaffectation des fichiers de données de MongoDB peuvent conduire à une certaine variation dans l'utilisation du stockage entre les nœuds. Les disparités en l'utilisation du stockage seront plus prononcées lorsque vous ajoutez des membres à différents moments.