Quel est le problème d'écriture mongod par défaut dans quelle version ?

Le problème d'écriture par défaut dans MongoDB était w:1 d'aussi loin que MongoDB 2.2 en 2012.

Il existe trois paramètres différents que vous pouvez utiliser pour configurer le problème d'écriture dans les versions actuelles de MongoDB (version 3.2.6 et plus récentes) :

• w réglage :combien de nœuds doivent accuser réception de l'écriture avant de la déclarer réussie. La valeur par défaut est 1, ce qui signifie que l'accusé de réception du nœud principal est suffisant.
• j réglage :les écritures doivent-elles être journalisées avant d'être reconnues ? La valeur par défaut dépend de writeConcernMajorityJournalDefault .
• writeConcernMajorityJournalDefault :si vous spécifiez w:majority paramètre de préoccupation d'écriture pour vos écritures sans définir j , quel est le j implicite évaluer? La valeur par défaut est true (les écritures doivent être journalisées dans la majorité des nœuds votants avant d'être reconnues).

Il existe également un wtimeout réglage pour configurer combien de temps MongoDB doit attendre que le problème d'écriture soit satisfait avant d'informer le client que l'écriture n'a pas été acquittée. Sinon, les écritures attendant que le problème d'écriture soit satisfait peuvent attendre indéfiniment au lieu d'échouer.

Le paramètre spécial ici est w:majority . Cela signifie que les écritures doivent se propager à la majorité des nœuds votants (ainsi qu'à leurs journaux) dans un jeu de répliques à accuser réception. Il s'agit sans doute du paramètre le plus sûr tout en offrant de bonnes performances, car :

• Il empêche l'annulation des écritures avec accusé de réception en cas d'échec.
• Il régule le débit de l'application afin qu'elle n'envoie pas d'écritures plus rapidement que ce que le jeu de répliques peut gérer (en raison de contraintes matérielles, de la situation du réseau, etc.).

Comme vous l'avez imaginé, les nœuds votants incluent l'arbitre . Ainsi, dans un jeu de répliques avec une configuration d'arbitre primaire-secondaire, w:majority pourrait échouer dans un scénario où :

• L'un des nœuds porteurs de données est hors ligne pour une raison quelconque.
• L'ensemble de réplicas est toujours en ligne avec un primaire accessible en écriture, puisque la topologie est maintenant arbitre primaire hors ligne.
• Écrit avec w:1 réussira comme d'habitude, mais ces écritures pourraient être annulées (puisqu'elles n'ont pas été écrites sur la majorité des nœuds contenant des données de vote).
• Puisque l'arbitre ne transporte aucune donnée, w:majority les écritures échoueront (ou attendront indéfiniment) puisque l'arbitre est compté comme un nœud votant.

Pour cette raison, l'utilisation d'un arbitre n'est pas recommandée si vous prévoyez d'utiliser w:majority dans votre application.

Veuillez noter que l'utilisation d'un arbitre dans un jeu de réplicas à 3 nœuds qui forme un fragment dans un cluster fragmenté n'est pas non plus recommandée, car les déplacements de blocs nécessitent w:majority . La défaillance d'un nœud porteur de données dans un fragment nuira aux opérations de migration de blocs.