Préoccupations d’écriture et durabilité confirmée

Une préoccupation d’écriture indique à MongoDB combien de membres de l’ensemble de réplication doivent confirmer une écriture avant que le pilote la considère comme réussie. Il s’agit du principal réglage permettant d’arbitrer entre la durabilité (davantage de confirmations = plus de sécurité) et la latence (moins de confirmations = davantage de rapidité). Chaque opération d’écriture — insertion, mise à jour, suppression ou remplacement — peut définir sa propre préoccupation d’écriture.

Le champ w contrôle le nombre de membres qui doivent confirmer l’écriture. w: 0 signifie lancer l’opération sans attendre de confirmation. w: 1 (valeur par défaut) signifie que seul le membre primaire doit confirmer. w: 2 signifie que le membre primaire et un membre secondaire doivent confirmer. w: 'majority' est le réglage recommandé en production : il attend la confirmation de la majorité des membres votants.

w: 'majority' garantit que l’écriture a été répliquée sur la majorité des membres votants avant que le pilote reçoive une réponse de succès. Cela signifie qu’un nouveau nœud primaire élu aura toujours vu l’écriture, même après un basculement. C’est le seul paramètre qui empêche l’annulation de données en cas de défaillance du nœud primaire.

L’option j (journal) contrôle si MongoDB attend que l’écriture soit validée dans le journal sur disque avant de l’accuser réception. Avec j: true, même une panne du serveur immédiatement après l’accusé de réception ne peut pas entraîner la perte de l’écriture. Sans journalisation (j: false), une panne survenant entre l’écriture en mémoire et la prochaine vidange du journal pourrait entraîner la perte de l’opération.

wtimeout définit la durée maximale (en millisecondes) pendant laquelle le serveur attend les accusés de réception w requis. Si le seuil n’est pas atteint à temps, MongoDB renvoie une WriteConcernError — mais l’écriture a bien été effectuée sur le nœud primaire. Un dépassement de délai signale un retard de réplication, et non un échec d’écriture.

w: 0 envoie l’écriture et renvoie immédiatement le résultat sans attendre le moindre accusé de réception. Cela maximise le débit pour les charges de travail à haut volume et tolérant la perte de données, comme la télémétrie, les événements analytiques ou l’ingestion de journaux, pour lesquelles des pertes occasionnelles sont acceptables. Ne l’utilisez jamais pour des transactions financières, du contenu généré par les utilisateurs ou toute donnée dont vous ne pouvez pas vous permettre la perte.

Lorsqu’un nœud primaire tombe en panne et qu’un nœud secondaire devient primaire, toutes les écritures que l’ancien nœud primaire n’avait pas encore répliquées sur la majorité sont annulées. Ces écritures annulées sont enregistrées dans un dossier d’annulation sur le disque afin de permettre une récupération manuelle. L’utilisation de w: 'majority' élimine ce risque, car l’écriture n’est confirmée qu’une fois qu’elle est présente sur la majorité.

Dans les transactions portant sur plusieurs documents, l’accusé de réception d’écriture s’applique lors de l’étape de validation, et non aux opérations individuelles exécutées dans la transaction. Valider avec w: 'majority' garantit que toutes les écritures de la transaction sont durables sur la majorité avant que l’application ne poursuive son exécution. Les accusés de réception définis au niveau des opérations dans une transaction sont ignorés.

Depuis MongoDB 5.0, l’accusé de réception d’écriture implicite par défaut est w: 'majority' pour les ensembles de réplication et les clusters partitionnés. Avant la version 5.0, la valeur par défaut était w: 1. Cela signifie que les déploiements MongoDB modernes sont sûrs par défaut, mais vous devez tout de même définir explicitement les accusés de réception d’écriture dans le code applicatif critique afin de garantir la clarté et la portabilité.

L’accusé de réception d’écriture peut être défini à trois niveaux : au niveau de l’opération (pour chaque insertion ou mise à jour), au niveau de la collection (lors de l’obtention d’une référence vers une collection) ou au niveau du client/de la chaîne de connexion. Les niveaux plus spécifiques remplacent les niveaux plus généraux. Le définir au niveau du client l’applique par défaut à toutes les opérations, tandis que les paramètres au niveau de l’opération conviennent mieux aux cas nécessitant des garanties de durabilité particulières.

Choisissez votre accusé de réception d’écriture en fonction de la criticité des données. Données financières ou transactionnelles : w: 'majority', j: true. Contenu utilisateur : w: 'majority'. Données de session ou de cache : w: 1. Télémétrie à haut volume : w: 0. Le bon choix établit un équilibre entre le coût de la perte de données et la pénalité de latence liée à l’attente d’accusés de réception supplémentaires.

Dans cette leçon, vous avez appris que l’accusé de réception d’écriture w contrôle le nombre de membres qui doivent confirmer une écriture, que w: 'majority' est le paramètre recommandé en production et empêche l’annulation après un basculement, et que j: true ajoute la durabilité du journal sur disque pour protéger les données contre les pannes. Nous allons maintenant étudier les préférences de lecture et la manière de répartir la charge de lecture sur l’ensemble de réplication.