Le « problème d'écriture » dans MongoDB décrit le niveau de reconnaissance d'écriture que vous pouvez en attendre. C'est un paramètre assez important à retenir dans vos opérations d'écriture et son comportement est utile à comprendre, en particulier dans les déploiements MongoDB distribués (c'est-à-dire les ensembles de réplicas et les clusters fragmentés). Dans cet article, nous discutons de 3 pièges lors de l'utilisation du problème d'écriture MongoDB.
Problème d'écriture MongoDB
La documentation de MongoDB définit le problème d'écriture comme "le niveau d'accusé de réception demandé à MongoDB pour les opérations d'écriture sur un mongod autonome ou sur des ensembles de répliques ou sur des clusters fragmentés. “
En termes simples, un problème d'écriture est une indication de la « durabilité » transmise avec les opérations d'écriture à MongoDB. Pour clarifier, regardons la syntaxe :
{ w: <value>, j: <boolean>, wtimeout: <number> }
Where*,
w can be an integer | "majority" | , it represents the number of members that must acknowledge the write. Default value is 1.
j Requests that a write be acknowledged after it is written to the on-disk journal as opposed to just the system memory. Unspecified by default.
wtimeout specifies timeout for the applying the write concern. Unspecified by default. * Vous pouvez trouver la syntaxe détaillée dans la documentation de la spécification Write Concern.
* En savoir plus sur les différentes "balises" que vous pouvez utiliser pour les valeurs de préoccupation d'écriture courantes dans notre blog Comprendre la durabilité et la sécurité d'écriture dans MongoDB.
Exemple :
db.inventory.insert(
{ sku: "abcdxyz", qty : 100, category: "Clothing" },
{ writeConcern: { w: 2, j: true, wtimeout: 5000 } }
) Le problème d'écriture de l'insert ci-dessus peut être lu comme suit : accusez réception de cette écriture lorsqu'au moins 2 membres de l'ensemble de répliques l'ont écrite dans leur journal dans les 5 000 ms ou renvoient une erreur '. Une valeur de préoccupation d'écriture pour l'option était majoritaire, ce qui signifie "rdemande la reconnaissance que les opérations d'écriture se sont propagées à la majorité des nœuds votants, y compris le nœud principal. “
#MongoDB Write Concern - 3 mises en garde à connaîtreClick To TweetL'importance de la préoccupation d'écriture est évidente. L'augmentation des valeurs de w augmente la latence des écritures tout en diminuant leur probabilité de se perdre. Le choix des valeurs correctes pour le problème d'écriture dépend des exigences de latence et de durabilité des écritures en cours.
Avec cela comme arrière-plan sur ce qu'est un problème d'écriture, passons aux trois mises en garde à retenir lors de l'utilisation d'un problème d'écriture.
CAVEAT 1 : la définition d'un problème d'écriture sur des jeux de réplicas sans délai d'expiration peut entraîner le blocage indéfini des écritures
La définition de la majorité (applicable à partir de MongoDB 3.0) ci-dessus indique qu'un accusé de réception est demandé à la majorité des « nœuds votants ». Notez que "Si vous ne spécifiez pas le wtimeout option et que le niveau de préoccupation en écriture est irréalisable, l'opération d'écriture sera bloquée indéfiniment. "
Cela peut avoir des conséquences inattendues, par exemple, considérez un jeu de réplicas 2+1 (c'est-à-dire un primaire, un secondaire et un arbitre). Si votre seul réplica en lecture tombe en panne, toutes les écritures avec une option d'inquiétude d'écriture w de « majorité » seront bloquées indéfiniment. La même chose se produira si l'option w est définie sur 2. Un autre exemple extrême est dans le cas d'un jeu de répliques 3+2 (primaire, 2 secondaires et 2 arbitres, configuration non recommandée). Toutes les écritures "majoritaires" seront bloquées même si un seul nœud de données n'est pas disponible car le nombre majoritaire, dans ce cas, est 3.
Le moyen le plus simple de résoudre ce problème consiste à toujours spécifier une valeur wtimeout afin que la requête puisse expirer si le problème d'écriture ne peut pas être appliqué. Cependant, en cas d'erreurs d'expiration de délai, MongoDB n'annule pas les écritures déjà réussies effectuées sur certains membres avant l'expiration du délai.
Il n'y a également actuellement aucun paramètre pour garantir qu'une écriture atteigne la majorité des nœuds actuellement accessibles, alors soyez prudent lorsque vous définissez la valeur de préoccupation d'écriture w en fonction de la topologie souhaitée. durabilité et disponibilité.
CAVEAT 2 : vous risquez de perdre des données même avec w :majority
Il semble intuitif qu'une fois qu'une écriture a été reconnue par la majorité des membres votants, sa durabilité est garantie. Cependant, ce n'est pas le cas ! N'oubliez pas que lorsque l'option j n'est pas spécifiée, une écriture est reconnue juste après avoir été écrite en mémoire.
Ainsi, une telle écriture peut être perdue si une coupure de courant anormale supprime la majorité des nœuds auxquels l'écriture s'est propagée (et avant syncPeriodSecs, c'est-à-dire avant qu'elle ne puisse être vidée vers disque).
Afin d'assurer la pérennité des écritures, il est préférable de ne pas désactiver la journalisation sur votre base de données et de définir l'option j sur true. En fait, à partir de MongoDB 3.6, le --nojournal flag est obsolète pour les membres du jeu de répliques utilisant le moteur de stockage WiredTiger.
Avec une valeur w de « majorité » et l'option j non spécifiée sur un jeu de répliques, le comportement de durabilité exact dépend de la valeur de la configuration du jeu de répliques writeConcernMajorityJournalDefault. Lorsqu'il est défini sur true (et lorsque la journalisation est activée), il accuse réception des écritures après qu'elles ont été écrites dans les journaux d'une majorité de membres votants.
En passant :même si la journalisation est activée, vos écritures peuvent toujours être perdues sur le moteur de stockage MMAPv1 si une panne se produit pendant la durée de commitIntervalMs. Le moteur de stockage WiredTiger, d'autre part, force une synchronisation des fichiers journaux lorsqu'il reçoit une écriture avec l'option j définie sur true. Et, même avec j défini sur false, une écriture "majoritaire" reconnue sur un dernier déploiement basé sur WiredTiger ne peut être perdue que lorsque la majorité des nœuds de données se bloquent simultanément.
CAVEAT 3 : w :0 lors de la définition de j :true n'améliore pas les performances d'écriture
C'est assez facile à raisonner une fois qu'on y pense, mais tout aussi facile à oublier. La définition de l'option w sur 0 est généralement effectuée pour écrire dans la base de données de manière "tirer et oublier" - lorsque vous avez une assez grande confiance dans l'infrastructure de la base de données et que vous vous souciez plus de la latence que de la durabilité de chaque écriture. Cependant, si vous définissez l'option j sur true, votre option w sera effectivement remplacée car la base de données s'assurera que l'écriture est écrite dans le journal sur disque avant de revenir.
Si vous utilisez des problèmes d'écriture pour garantir le succès de vos opérations d'écriture, assurez-vous de vous souvenir de ces trois mises en garde cruciales ! Nous sommes là pour vous aider, alors n'hésitez pas à nous contacter pour toute question via Twitter ou par e-mail.
