Même si la journalisation est allumée, est-ce qu'il y a toujours une chance de perdre des écrivies dans mongodb?
"Par défaut, la plus grande étendue des écrivies perdues, c'est-à-dire que celles non apportées au journal sont celles faites dans les 100 derniers millisecondes."
Ceci est de gérer la journalisation , ce qui indique que vous pourriez perdre des écrivies réalisées depuis la dernière fois que le Journal a été rincé sur le disque.
Si je veux plus de durabilité, "Pour forcer Mongod à s'engager dans le journal plus fréquemment, vous pouvez spécifier J: TRUE. Lors d'une opération d'écriture avec j: TRUE est en attente, Mongod réduira le journalCommitterval à un tiers de la valeur définie. . "
Même dans ce cas, on dirait que la revente du journal sur le disque est asynchrone, il reste encore une chance de perdre des écrivies. Est-ce que je manque quelque chose sur la façon de garantir que les écritures ne sont pas perdues?
5 Réponses :
Je serais à être d'accord avec Sammaye que Journoualing a peu à voir avec la durabilité. Toutefois, si vous voulez avoir une réponse si vous pouvez vraiment faire confiance à Mongodb pour stocker vos données avec une bonne cohérence, je vous suggère de lire ce blog post . Il y a une réponse de 10gen concernant ce poste et une réponse de l'auteur à la poste 10gen. Je suggérerais que vous lisiez à cela pour prendre une décision éduquée. Il m'a fallu un peu de temps pour comprendre tous les détails, mais ce post a les bases couvertes.
La réponse au blog post a été donnée ici par 10gen < / a>, la société qui fait mongodb.
Ce poste de blog est un peu unilatéral et inacaturé parfois, le gars en fait un développeur pour un concurrent de MongoDB et l'a écrit comme une guerre de flamme et l'a affiché sur l'article de Wikipedia MongoDB au trafic direct. Même s'il fait l'état sur un point de vue sur le point de vue de la revue qui n'ait été acheminé que sur les autres membres et non, il est de savoir s'il est logique de pouvoir avoir à ACK Journal sur une base de données partitionDERD.
@Sammaye: Je suis d'accord, (sauf à propos de la partie inexacte), mais voici la chose, elle touche une large gamme de problèmes, pour un. Je ne dirais pas qu'il est parfois inexact, je pense juste qu'il a tendance à pousser l'acide et la consistance dans le cadre de DBS NOSQL. Deuxièmement, il y a une réponse de 10gen qui élimine certaines des revendications qu'il fait, puis il y a une contre-réponse. Je pense que c'est la meilleure façon de juger Mongo, car il y a des déclarations des deux côtés.
Dunno votant sur donc est parfois très étrange, on pourrait dire que la source unique n'est pas assez bonne pour une réponse, certaines personnes détestent des réponses à source unique; bien quand je dis parfois je veux dire toujours
SRY, comprimé accidentel Cliquez sur. Corrigée :)
@Borisb. Pas de soucis, merci pour ça. S'il y a quelque chose qui ne va pas avec ma réponse, je le répare habituellement tout de suite.
Peut-être. Oui, il attend que les données soient écrits, mais selon les docs, il y a un 'thère est une fenêtre entre Journal commet une fois que l'opération d'écriture n'est pas entièrement durable ', quoi que ce soit. Je ne pouvais pas découvrir ce qu'ils se réfèrent.
Je quitte la réponse éditée ici, mais je me suis renversé de retour et de retour, il est donc un peu irritant:
Ceci est un peu délicat, car il y a beaucoup de leviers que vous pouvez tirer:
supposant que la journalisation est activée (par défaut pour 64 bits ), la revue sera commise à intervalles réguliers. La valeur par défaut pour le Vous pouvez également modifier le L'inquiétude d'écriture Vous devez spécifier une préoccupation écrite qui indique au pilote et à la base de données d'attendre que les données soient écrites sur le disque. SO, au meilleur , il y a une fenêtre 2 ms où les données peuvent être perdues. Cela est insuffisant pour un certain nombre d'applications, cependant. La commande Même si vous deviez journaliser toutes les écritures, qu'est-ce qu'il est bon pour si l'administrateur de Datacenter a une mauvaise journée et utilise une tronçonneuse votre matériel ou le matériel se désintègre simplement? stockage redondant, non sur un niveau de périphérique de bloc tel que le raid, mais sur un niveau beaucoup plus élevé est une meilleure option pour de nombreux scénarios: avoir les données dans différents endroits ou au moins sur différentes machines à l'aide d'un réplique Ceci offre le meilleur compromis des performances, durabilité et de la cohérence. En outre, cela vous permet d'ajuster la préoccupation écrite pour chaque écriture et offre une bonne disponibilité. Preuve La documentation peut être un peu irritante, notamment en ce qui concerne dans notez l'appel qui explique ce que JournalCommitInterval est de 100 ms Si le journal et les fichiers de données sont sur le même périphérique de bloc, ou 30ms si elles ne sont pas (elles sont donc préférables Pour avoir le journal sur un disque séparé). JournalCommiTerval en 2 ms, mais il augmentera le nombre d'opérations d'écriture et réduire les performances globales de l'écriture . Cependant, cela n'attendra que lorsque les données ont été réellement écrites sur le disque, car cela prendrait 100 ms dans un scénario mauvais avec la configuration par défaut. FSYNC FSYNC Flush de tous les fichiers de données, mais il est inutile si vous utilisez la journalisation, et c'est inefficace. w: majorité écrivez votre inquiétude avec la journalisation activée (la journalisation ne s'appliquera que sur le primaire, bien que ). Utilisez RAID sur les machines individuelles pour augmenter votre chance. Si les données sont en file d'attente pour le prochain FSYNC sur trois machines différentes, il pourrait toujours y avoir 30 ms au prochain journal commettre sur l'une des machines (pire des cas), mais les chances de trois machines descendant dans l'intervalle de 30 ms sont Probablement un million de fois inférieur au scénario-Massacre-admin.
TL; DR: Je pense que ma réponse ci-dessus est correcte. wimeout , donc j'ai vérifié la source. Je ne suis pas un expert sur la source de Mongo, alors prenez cela avec un grain de sel: write_concern.cpp , nous trouvons (édité pour la brièveté): MemoryMappileFile :: flushall (vrai) si FSYNC est défini. Cet appel n'est clairement pas dans la première branche. Sinon, la durabilité est traitée sur un thread séofate (fichiers pertinents préfixés dur _ ).
wtimeout est pour: il fait référence à l'heure en attente des esclaves et n'a rien à voir avec des E / S ou FSYNC sur le serveur. < / p>
Exactement la faiblesse des Mongodbs est également sa force avec durabilité lorsqu'il s'agit d'utiliser la base de données dans son réglage prévu en dehors du serveur unique sur des partitions potentiellement multiples, non seulement cela, mais beaucoup de gens qui disent que Mongodb n'est pas durable de théorie alors que dans vraie vie que la théorie ne tiendrait jamais ...
Ce n'est pas une faiblesse, en fait, c'est une fonctionnalité: l'innoDB de MySQL a introduit un rinçage adaptatif ( dev.mysql.com/doc/innodb/1.1/fr/glossary.html ) en tant que nouvelle fonctionnalité de la version 5.1. Je conviens que la définition pure CS de la durabilité est difficile à appliquer à la vie réelle, car elle ne considère pas les problèmes à des niveaux plus élevés.
Êtes-vous sûr que le WRITECONCERN avec l'OPion J: 1 n'attendra pas que la mise à jour soit écrite dans le fichier journal?
hmm ... plus grand. Les docs sont un peu contradictoires. Il y a un «fil de durabilité» dans MongoDB qui appelle régulièrement la chasse. Je vais creuser un peu plus loin pour m'assurer.
La fenêtre est quelque chose entre 30-100ms, j'ai demandé à 10Gen de résoudre une fois une fois avant et être plus précis sur la manière dont la journalisation fonctionne, semble qu'elles ne l'ont pas encore ... aussi avec J The DRUT n'attendra jamais plus longtemps que JournalCommitterval / 3
Oui, mais le fait que c'est un tiers du journalCommitterval est intentionnel (DUR.CPP Line 800). Je ne sais pas où provient la fenêtre de la perte de données. Dur.CPP Line 658 dit 'ok to Crash après cela', puis notifie les commandes en attente ... Hmm. Savez-vous s'il y a une question de Jira pour cela?
Je ne connais pas celui que je dois être honnête. J'ai eu connaissance sur une autre question comme celle-ci sur l'utilisation de J dans Replica Ensems et Asya a déclaré l'info et je viens de dire qu'il serait bon d'ajouter cela aux docs ... donc ouais : /
Dans la branche principale, Mnemosyn a dit dans Dur.cpp Appel 655 Call Writetojournal et 659 commettre la commande getlasterror, si je l'ai bien compris, avant l'IPL. de la Writetojournal à Dur_Journal.cpp à 699 Il y a un commentaire: "Écrire (Ajouter) le tampon que nous avons construit au journal et à FSYNC IT.", cela signifie que pour moi, il n'y a pas de fenêtre pour perdre des données de ce point de vue, pendant que la commande fsyncs aussi.
Généralement perdu écrit constitue un problème dans tous les systèmes où il y a une mémoire tampon / mise en cache / retardée - écrire impliqué entre le temps d'exécution d'un système et un stockage permanent (non volatile), même au niveau du système d'exploitation (par exemple, la mise en cache d'écriture) . Il y a donc toujours une chance de perdre des écrivies, même si votre fournisseur de béton (MongoDB) fournit des fonctionnalités de la durabilité de la transaction C'est le système d'exploitation sous-jacent responsable de la rédaction de données, et même il y a la mise en cache à Le niveau de l'appareil ... et ce n'est que des niveaux inférieurs, ce qui rend le système hautement concomitant, distribué et performant ne fait que pire.
En bref, il n'y a pas de durabilité absolue, uniquement pratique / éventuelle / espoir - la meilleure durabilité, en particulier avec un stockage NOSQL comme Mongo, qui n'est pas principalement faite pour la cohérence et la durabilité.
J'appellerais ces considérations, pas des problèmes. Bien que les méthodes les plus couramment utilisées pour écrire sur le disque, passez à travers les optimisations de mise en cache habituelles, les systèmes d'exploitation et même les interfaces matérielles fournissent les moyens de faire des écrivies qui réussissent lorsque les données sont en toute sécurité sur le stockage sous-jacent. L'existence FSYNC et les barrières contradictent directement ce que je crois, c'est la thèse de votre premier paragraphe; que vous n'avez pas de contrôle définitif sur les caches et la connaissance des données en toute sécurité sur le stockage.
La journalisation consiste à maintenir les données sur un Mongod particulier dans un état cohérent, même en cas de folie de la tronçonneuse, toutefois avec les paramètres du client via WriteConcertan, il peut être utilisé pour forcer la durabilité. À propos de Ecrire une préoccupation docs .
Il y a une option, Si vous exécutez de nombreuses commandes avec une telle option MongoDB adaptera la taille de l'intervalle de validation du journal pour accélérer les choses, vous pouvez en lire ici: Docs Celui-ci que vous avez également mentionné et comme d'autres personnes ont déjà dit que vous pouvez spécifier un intervalle entre 2-300ms.
La durabilité est beaucoup plus assurée à mon avis sur l'option W: 2 tandis que si l'opération de mise à jour / écriture est reconnue par deux membres dans un réplicaset, il est vraiment peu probable de perdre les deux dans la même minute (intervalle de chasse de Datafile), mais pas impossible.
L'utilisation des deux options entraînera la situation que lorsque l'opération est acquittée par le cluster de base de données, il réside dans la mémoire dans deux cases différentes et sur une autre, il sera également dans un lieu de disque recouvrable cohérent. j: 1 , que vous pouvez lire sur ici qui garantit que l'opération d'écriture particulière attend l'accusé de réception jusqu'à ce qu'elle soit écrite dans le fichier de journal sur disque (donc pas seulement dans la mémoire de la mémoire). Cependant, ce docs dit le contraire. :) Je voterais pour le premier cas, cela me rend plus à l'aise.
Poster une nouvelle réponse pour la nettoyer. J'ai effectué des tests et lisez à nouveau le code source et je suis sûr que l'irritation provient d'une phrase malheureuse dans le Écrire une documentation sur l'inquiétude . Avec la journalisation activée et Même si la journalisation est allumée, est-ce qu'il y a encore une chance de perdre des écritures dans mongodb?
Oui, car la durabilité dépend également de l'inquiétude des opérations individuelles. "Par défaut, la plus grande étendue des écritures perdues, c'est-à-dire que celles non apportées au journal sont celles faites dans les 100 derniers millisecondes."
Cela provient de la réalisation de la gestion, qui indique que vous pouvez perdre des écrivies faites depuis la dernière fois que le journal a été rincé sur le disque.
c'est correct. Le journal est rincé par un fil séparé de manière asynchrone, de sorte que vous puissiez tout perdre depuis la dernière rinçante. Si je veux plus de durabilité, "Pour forcer Mongod à s'engager dans le journal plus fréquemment, vous pouvez spécifier Cela m'a irrité aussi. Voici ce que cela signifie: Lorsque vous envoyez une opération d'écriture avec à la place, que se passe-t-il, c'est que le «fil de durabilité» prendra tout le journal en attente et les rincera au disque. Le thread est implémenté comme ceci (commentaires mine): donc un Même dans ce cas, on dirait que la revente du journal sur le disque est asynchrone, il reste encore une chance de perdre des écrivies. Est-ce que je manque quelque chose sur la façon de garantir que les écritures ne sont pas perdues?
la commande écriture (ou la phrase "Cependant, il existe une fenêtre entre Journal commet quand l'opération d'écriture n'est pas entièrement durable "Il s'agit probablement d'un Mongod en cours d'exécution avec la journalisation activée qui accepte une écriture qui fait pas utilise le J'ai déposé un Signaler des bogues DOCS pour cela. j: true Ecrire une inquiétude, l'écriture est durable et il n'y a pas de fenêtre mystérieuse pour la perte de données.
j: true . Lors d'une opération d'écriture avec j: true est en attente, Mongod réduira JournalCommiTerval à un tiers de la valeur définie. "
j: true , il ne déclenche pas le disque flush immédiatement et non sur le thread du réseau. Cela a du sens, car il pourrait y avoir des dizaines d'applications parlant à la même instance de Mongod. Si toutes les applications devaient utiliser beaucoup de journalisation, la DB serait très lente car elle est fsyncing tout le temps. J: true opérationnera le fil de validation de la revue commettant plus tôt que Cela ferait normalement, et il s'engagera tout en attente d'écriture en attente au journal, y compris ceux qui n'ont pas J: vrai défini.
getlasterror ) avec un j: true Journaled Write Cruck attendra que le fil de la durabilité finisse de la synchronisation < / EM>, il n'y a donc aucun risque de perte de données (aussi loin que la garantie du système d'exploitation et du matériel que). j: true Ecrire une préoccupation. Dans ce cas, il y a une chance de se perdre depuis le dernier journal commit.
Oui, vous pouvez techniquement perdre des données dans les 1 000e (je pense que c'est que cela pourrait être 10 000e) d'une seconde, je vous ai juste besoin de vous remettre en question si vous allez vraiment avoir suffisamment de trafic pour cela, en doutez personnellement
Il convient de mentionner que la journalisation n'a rien à voir avec la durabilité, il assure la cohérence des fichiers de données après une fermeture non planifiée. C'est son travail. Les écrires de disque sont quelque chose de plus intué avec la durabilité, bien sûr dans MongoDB qui se trouve être le journal. Cependant, même dans ce cas, ce n'est pas "directement au disque"