FAQ MongoDBConsultez toutes les FAQ

Nombre d'auteurs : 1, nombre de questions : 331, dernière mise à jour : 18 décembre 2016  Ajouter une question

 

Cette FAQ a été réalisée à partir de la documentation officielle de Mongodb, des questions fréquemment posées sur les forums NoSQL Developpez.com et de l'expérience personnelle des auteurs.

Nous tenons à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci.


SommaireRéplication et Replica Sets (16)
précédent sommaire suivant
 

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Si votre déploiement MongoDB utilise TLS/SSL, toutes les communications entre les arbitres et les autres membres du replica set sont sécurisés. Consultez la documentation de Configuration des mongod et mongos pour TLS/SSL pour plus d'informations. Exécutez tous les arbitres sur des réseaux sécurisés, comme avec tous les composants MongoDB.

Voir la vue d'ensemble des Membres arbitres des replica set.

Mis à jour le 11 décembre 2016

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

Voir aussi : Élections replica set.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2020 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.