dans le documentation SQLITE sur la fonction de journal écriture-avions introduite dans la version 3.7 , il y a quelques commentaires qui me confondus un peu.
La page liée indique "Synchroniser le contenu sur le disque n'est pas requis, tant que la demande est disposée à sacrifier la durabilité à la suite d'une perte de puissance". Ensuite, deux paragraphes en baisse, il est indiqué que "le point de contrôle nécessite des opérations de synchronisation afin d'éviter la possibilité de corruption de base de données après une perte de puissance ou un redémarrage dure" ".
est donc ma base de données à plus grand risque de corruption sur la perte de puissance si j'utilise WAL?
3 Réponses :
Il n'y a pas de risque accru de corruption avec WAL (puisqu'il utilise des opérations de synchronisation lorsque le point de contrôle).
Cependant, s'il y a un crash (perte de puissance ou redémarrage du disque dur), vous perdrez des transactions depuis le dernier point de contrôle; C'est ce que l'on entend par «sacrifier la durabilité».
Je sais que cette réponse est vieille, mais elle a une erreur plutôt importante. Vous ne perdrez pas de transactions depuis le dernier point de contrôle, vous perdrez des transactions qui n'ont pas encore été entièrement écrites au WAL. Si synchrone = normal, il n'attend pas un FSYNC () lors de l'écriture de la transaction vers le Wal, vous risquez donc de perdre cette transaction si vous perdez la puissance avant qu'elle ne soit complètement écrite. Une fois que c'est dans le Wal, il ne sera pas perdu, quel que soit le point de contrôle.
Jusqu'au 2016-02-17 SQLITE.ORG/DOCSRC/INFO/3540D671BCC4835C La documentation SQLITE dit que synchrones = normal par défaut par défaut en mode WAL ... Il est maintenant dit synchrone = Plein - beaucoup plus sûr par défaut. Donc, vous perdrez des transactions avant le point de contrôle uniquement si vous définissez synchrones = mode normal
Pour répondre pleinement, nous devons savoir ce que vous avez Lorsque vous citez "tant que la demande est disposée à sacrifier la durabilité à la suite d'une perte de puissance", cela se réfère à avoir avoir la meilleure résiliance contre les données perdues, vous pouvez souhaiter Pragma Synchrone défini sur, car cela affecte quand fdataSync () est appelé et donc lorsque les tampons ont rougés sur le lecteur physique.
synchrone = normal . Ici, le wal est uniquement synchronisé sur le disque lorsque le point de contrôle se produit (un fdataSync () pour le WAL et un pour la DB principale après sa fusionne). Vous devriez être protégé contre la corruption assez bien, mais il peut y avoir des écrivies qui ne l'ont jamais rendue au plateau et sont donc perdues: d'où la durabilité perdue. L'avantage est beaucoup moins de la lente fdatasync () pour synchroniser les données.
synchrone = plein . Cela gagne une durabilité, mais le coût est un fdataSync () par transaction d'écriture. Cependant, c'est encore mieux que le mode non wal où il y aurait deux fdataSync () appels - un pour le journal de transaction et un pour la DB principale.
Tant que les appels de synchronisation sur votre système d'exploitation fonctionnent parfaitement, vous risquez de désactiver une DB corrompue. Cependant, cela peut ou non être le cas - voir la documentation SQLite pour une explication plus longue à ce sujet.
Pour corriger Doug Currie (voir POST DE MATTR): Vous ne risquez que de perdre des transactions si @ synchrones = normal @. Si @ synchrone = complet @ (qui est par défaut), vous ne sacrifiez pas la durabilité. Voir http://www.sqlite.org/draft/wal.html pour plus de détails sur ceci.
Je crois que la journalisation WAL est en fait plus sûre que la journalisation «classique» (en cas de synchronisation du système imparfait), car la chance que la DB ait quelque chose de critique à un moment donné est plus basse jusqu'à ce que je comprenne la journalisation Wel. Cependant, je n'ai actuellement aucune donnée difficile pour l'appuyer.