Depuis 20 ans, PostgreSQL aurait mal utilisé fsync(), compromettant la cohérence des données,
Des solutions ont été proposées au FOSDEM 2019

Le , par Bill Fassinou

320PARTAGES

14  1 
C’est au FOSDEM de cette année qui a eu lieu ces 2 et 3 février à Bruxelles que le sujet a été abordé à nouveau par Thomas Vondra, un ingénieur de base de données et contributeur au projet PostgreSQL. Il s’agit de l’implémentation de fsync au sein du gestionnaire de base de données PostgreSQL. D’après ces propos, fsync() ne marche pas réellement comme on le pense sur Linux et d’autres systèmes BSD et peut ainsi avoir des conséquences potentiellement désastreuses pour la durabilité/cohérence des données.

Le paramètre fsync() permet de transférer toutes les données internes modifiées d’un fichier référencé par le descripteur de fichier fd (c'est-à-dire les pages de cache tampon modifiées) vers le périphérique de disque (ou un autre périphérique de stockage permanent), de sorte que toutes les informations modifiées puissent être récupérées même après une panne du système ou son redémarrage. Cela inclut l'écriture ou le vidage d'un cache de disque, le cas échéant. L'appel est bloqué jusqu'à ce que l'appareil signale que le transfert est terminé. Seulement, ce n’est pas exactement ce que fait la fonction avec le serveur de base de données PostgreSQL.

Si ce paramètre est activé, indique la documentation du serveur PostgreSQL, ce dernier essayera de s’assurer que les mises à jour sont écrites physiquement sur le disque en émettant des appels fsync() système ou diverses méthodes équivalentes. Cela garantit que le cluster de base de données peut retrouver un état cohérent après une panne matérielle ou du système d'exploitation. Toujours dans cette documentation, il est noté que, bien que la désactivation de fsync() soit souvent un avantage en termes de performances, cela peut entraîner une corruption irrémédiable des données en cas de panne de courant ou de panne du système.

Il est donc conseillé de désactiver cette fonction fsync si vous pouvez facilement recréer toute votre base de données à partir de données externes dans le cas contraire ne le faites pas. Le problème abordé par Vondra a été signalé pour la première fois en mars de l’année dernière par Craig Ringer, un ingénieur en base de données. Il prévenait que la gestion des erreurs fsync() par PostgreSQL est dangereuse et risque de provoquer une perte de données sur XFR. Ensuite Jonathan Corbet, un autre ingénieur en base de données a apporté plus d’explications sur le sujet en avril dernier.


PostgreSQL, dit-il, suppose qu’un appel réussi à fsync() indique que toutes les données écrites depuis le dernier appel réussi sont passées en toute sécurité au stockage persistant. Mais ce n'est pas ce que fait le noyau. Lorsqu'une écriture d'E/S en mémoire tampon échoue en raison d'une erreur matérielle, les systèmes de fichiers répondent différemment, mais ce comportement implique généralement de supprimer les données des pages affectées et de les marquer comme étant propres. Ainsi, une lecture des blocs qui viennent d'être écrits retournera probablement autre chose que les données écrites.

De plus, continue-t-il dans son explication, même avant que la communauté n'entre dans la discussion, il était devenu évident que la situation n'était pas aussi simple qu'il n’y paraissait. Thomas Munro a indiqué que Linux ne se comportait pas de la sorte. OpenBSD et NetBSD peuvent également ne pas rapporter d’erreurs d’écriture dans l’espace utilisateur. Et il s’avère que la façon dont PostgreSQL traite les E/S en mémoire tampon complique considérablement l’image. Le serveur PostgreSQL s'exécute comme un ensemble de processus dont beaucoup peuvent effectuer des E/S sur les fichiers de base de données.

Le travail d'appel de fsync() cependant, est traité dans un processus unique “checkpointer", qui consiste à maintenir le stockage sur disque dans un état cohérent pouvant être restauré à partir d'échecs. Le point de contrôle ne laisse normalement pas tous les fichiers pertinents ouverts. Il doit donc souvent ouvrir un fichier avant d'appeler fsync() dessus. C’est là que le problème se pose, souligne-t-il. Même dans les noyaux 4.13 et ultérieurs, le checkpointer ne verra aucune erreur survenue avant l’ouverture du fichier. Si quelque chose de grave se produit avant l'appel de la fonction open() du checkpointer, le paramètre fsync() retournera simplement un succès.

Alors, comment résoudre un tel problème ?

Avant cette question, plusieurs propositions avaient été faites pour résoudre le problème, mais ces solutions étaient toutes à court terme. Certains internautes ont pensé à adopter le mécanisme de la gestion des entrées/sorties mises en place par Google (le noyau a été instrumenté pour signaler les erreurs d'E/S via un socket netlink. Un processus dédié reçoit ces notifications et répond en conséquence) et d’autres ont proposé de définir un indicateur dans le superbloc du système de fichiers lorsqu’une erreur d’E/S se produit.

Une autre proposition était de répondre à une erreur d'E/S en marquant le fichier lui-même (dans l'inode) comme étant dans un état d'erreur persistante. Cependant, un tel changement éloignerait davantage le comportement de Linux des mandats POSIX et soulèverait d'autres questions notamment : quand et comment cet indicateur serait-il effacé ? Donc, ce changement semble peu probable ou peu envisageable. Au FOSDEM 2019, Vondra a lui aussi, proposé deux solutions temporaires.

La première concerne la modification du noyau de Linux et la seconde demande de déclencher PANIC au sein de PostgreSQL pour tenter d’avoir des rapports d’erreurs un peu plus précis. Lorsqu’on choisira de modifier le noyau, précise-t-il, cela nécessitera sans aucun doute beaucoup de temps, mais il pourrait payer à la fin. Ce travail permettra tout simplement de retravailler le comportement de fsync. La deuxième méthode consiste à activer les messages PANIC dans PostgreSQL pour déclencher des types d’erreurs spécifiques et de pouvoir les imprimer dans les fichiers journaux.

Cette deuxième action nécessite que les postes exécutant le serveur PostgreSQL soient dotés d’une version supérieure ou égale à la version 4.13 du noyau. D’après certains commentaires des internautes, les systèmes de fichiers modernes sont parfois la cause du manque de performance de certaines applications. Selon eux, cela pousse des fois des développeurs d’applications à abandonner l’idée de développer leur solution pour telle ou telle plateforme et dans la plupart des cas, Linux.

Source : FOSDEM, Vidéo de la présentation, LWN.net

Et vous ?

Que pensez-vous de ce problème ?
Quelles autres solutions préconiseriez-vous pour régler le soucis ?

Voir aussi

Disponibilité générale de PostgreSQL 11 : un aperçu des principales fonctionnalités du SGBDRO libre

Microsoft fait l'acquisition de Citus Data l'extension qui transforme PostgreSQL en une base de données distribuée

Emploi développeur 2017 : les SGBD les plus demandés et les mieux payés, MySQL, MongoDB et PostgreSQL plus demandés mais MongoDB et DB2 mieux payés

DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017, quels étaient vos SGBD préférés en 2017 ?

Microsoft Azure embarque une nouvelle offre NoSQL et deux nouveaux services de bases de données pour un support natif de MySQL et PostgreSQL

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de pachot
Expert éminent https://www.developpez.com
Le 12/02/2019 à 8:07
Vu l'importance des écritures (performances et fiabilité) pour une base de données, tous les autres SGBD accèdent aux disques en Direct I/O et gèrent leur propre buffering et cache. C'est probablement la seule solution à long terme. Mais vu que PostgreSQL a toujours compté sur le cache filesystem pour simplifier le code d'accès aux données, ouvrir les fichiers en O_SYNC ne serait probablement pas viable en termes de performance sans une grosse évolution du code, et rendrait difficile la portabilité sur différents OS.
4  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 12/02/2019 à 9:48
Une des différences majeures que je montre dans mes cours est basée sur le fait que les grands SGBDR comme IBM DB2, Oracle ou MS SQL Server ont un OS interne qui gère la mémoire (donc le cache à tous les niveaux), les threads interne à l'OS - ne serait ce que pour les prioriser, les planfifier et gérer le parallélisme au sein d'une même requête - et enfin gèrent le disque de manière directe en squeezant l'OS hôte (Windows, Linux...) afin d'être certain que les écritures soient effectives et aussi pour des raisons de performances...

Encore une fois il existe des différences très importante entre des produits "libres" quelque peu brouillon et totalement irresponsables et des outils délivrés par des éditeurs qui sont pensés à long termes par des équipes dédiées et qui engage la responsabilité de l'éditeur !

Bref, il n'y a pas photo sur le plan des fonctionnalités, bugs et sécurité entre le libre et le commercial, même si PostGreSQL reste un excellent choix pour de petites config (bases de moins de 300 Go, moins de 100 utilisateurs simultanés, faible complexité des requêtes et transactions, et surtout pas de 24h/24 7j/7...) par rapport à MySQL farci de bugs d'à peu près et à la sécurité plus qu'incertaine !

Pour information, certains états de la CEE, autrefois grands supporter du libre, et notamment la suède ou a été conçue MySQL, interdisent dorénavant l'usage de logiciels libre dans l'administration...
3  8 
Avatar de pachot
Expert éminent https://www.developpez.com
Le 12/02/2019 à 15:01
Et pour info, un test que j'avais fait à l'époque pour voir les conséquences sur les IOPS en montant les filesystem en O_SYNC:
https://blog.dbi-services.com/postgr...or-postgresql/

Sinon, pour la petite histoire, Microsoft a fait la même erreur en portant SQL Server sur Linux, car les fichiers étaient ouverts en O_DIRECT seulement. Ils ont vite corrigé ça dès SQL Server 2017 CU8 (https://support.microsoft.com/en-us/...-2017-on-linux).
5  0 
Avatar de Volgaan
Membre averti https://www.developpez.com
Le 12/02/2019 à 16:20
Citation Envoyé par SQLpro Voir le message
Encore une fois il existe des différences très importante entre des produits "libres" quelque peu brouillon et totalement irresponsables et des outils délivrés par des éditeurs qui sont pensés à long termes par des équipes dédiées et qui engage la responsabilité de l'éditeur !
Quel est le rapport entre le libre - un mouvement, une philosophie de développement - et la qualité d'un logiciel ? Encore un discours de quelqu'un qui veut enfoncer le « méchant logiciel libre »

En plus, il existe de très bons logiciels libres (dont certains sont même développés par des entreprises - c'est pas le cas de PostegreSQL d'ailleurs ?) tout comme il existe de médiocres logiciels propriétaires. Licence ne vaut pas qualité !

Sans oublier la quantité hallucinante de bibliothèques libres qui sont utilisées (souvent sans reconnaissance) dans les projets commerciaux (y compris de grands noms comme Apple, Microsoft, Google...).

Citation Envoyé par SQLpro Voir le message
Bref, il n'y a pas photo sur le plan des fonctionnalités, bugs et sécurité entre le libre et le commercial, même si PostGreSQL reste un excellent choix pour de petites config (bases de moins de 300 Go, moins de 100 utilisateurs simultanés, faible complexité des requêtes et transactions, et surtout pas de 24h/24 7j/7...) par rapport à MySQL farci de bugs d'à peu près et à la sécurité plus qu'incertaine !
Du peu que j'en sais, PostegreSQL est considéré comme un excellent SGBD, même face aux produits commerciaux concurrents. Et je suis à peu près sûr qu'il est capable de tourner sans interruption.

Citation Envoyé par SQLpro Voir le message
Pour information, certains états de la CEE, autrefois grands supporter du libre, et notamment la suède ou a été conçue MySQL, interdisent dorénavant l'usage de logiciels libre dans l'administration...
Ils interdisent ou ils privilégient plutôt des produits commerciaux ? La nuance est importante !

Et pourquoi vouloir l'interdire de toute façon ? Car des lobbies font pression derrière ? Parce que ça « fait peur » ?
6  1 
Avatar de MaximeCh
Membre éclairé https://www.developpez.com
Le 12/02/2019 à 17:22
la délégation aux kernel et système de fichier de l'écriture bas niveau est-elle une mauvaise chose?
Est-ce que l'argument d'autorité que les vénérables db2, mss et oracle font du directIO a une quelconque valeur?
N'importe quelle application d'envergure tournera sur un RAID6, et probablement sur une installation électrique avec alimentation de secours.

@SQLPro, qui a apporté de superbes contributions au site, continue de s'enfermer dans le cliché de l'initié qui vit du savoir pro-proprio,
il ne sert à rien de répéter que postgre ne supporte pas la charge 24/7/365, c'est de moins en moins vrai voire ne l'est plus du tout.
5  1 
Avatar de Asphator
Nouveau membre du Club https://www.developpez.com
Le 12/02/2019 à 17:39
Certains systèmes bancaires français font transiter leurs transactions via des plateformes full linux/postgres, 24/7/365 (of course), et ce depuis la 9.2.
Donc c'est tout à fait viable et long terme
1  0 
Avatar de pachot
Expert éminent https://www.developpez.com
Le 12/02/2019 à 18:16
Citation Envoyé par MaximeCh Voir le message
Ensuite sur le fond, la délégation aux kernel et système de fichier de l'écriture bas niveau est-elle une mauvaise chose?
Est-ce que l'argument d'autorité que les vénérables db2, mss et oracle font du directIO a une quelconque valeur?
N'importe quelle application d'envergure tournera sur un RAID6, et probablement sur une installation électrique avec alimentation de secours.
Au kernel, oui, de plus en plus. Par exemple, les I/O asynchrones sont délégués au kernel là où avant les SGBD se chargaient d'avoir plusieurs writers.
Au système de fichier... ils sont en général développés pour des choses très différentes d'une base de donnée. Pour gérer des fichiers et des répertoires. Très différent de blocs de données.
Effectivement les pannes disque sont plus rares aujourd'hui, mais ce n'est pas une raison pour les ignorer. Une écriture perdue, sans s'en apercevoir, peut être catastrophique: on s'apercoit de la corruption des mois après sans pouvoir le restaurer. Ou on ne s'en apercoit pas et la transaction est simplement perdue. Par contre, la rareté de ces pannes fait qu'il est acceptable de stopper l'instance en case d'erreur, là où il y a quelques années on retentait l'écriture. C'est une piste pour PostgreSQL: detecter l'erreur et sortir en panic.

Sinon, sur open-source vs. commercial, je ne crois pas que d'avoir ignoré le problème du fsync() viennent du fait que ce soit un projet open-source. Au-contraire, la communauté réagit très bien et les développements vont assez vite. C'est plutôt le fait du démarrage universitaire du projet. Mais c'est sûr que les bases de données commerciales mettent la priorité sur la fiabilité et disponibilité.

Citation Envoyé par SQLpro Voir le message
Bref, il n'y a pas photo sur le plan des fonctionnalités, bugs et sécurité entre le libre et le commercial
On a pas dit la même chose pour les systèmes d'exploitation quand Linux est arrivé? Mais maintenant, en entreprise, on ne voit plus trop de HP-UX, Solaris, AIX... Même Microsoft a porté son SGBD sur Linux. Et IBM a racheté RedHat. Linux et GNU font tourner les bases critiques dans beaucoup d'entreprise.
7  0 
Avatar de Fleur en plastique
Membre habitué https://www.developpez.com
Le 12/02/2019 à 18:18
Citation Envoyé par SQLpro Voir le message
Une des différences majeures que je montre dans mes cours
C'est un plaisir d'échanger avec vous Professeur.

Citation Envoyé par SQLpro Voir le message
Encore une fois il existe des différences très importante entre des produits "libres" quelque peu brouillon et totalement irresponsables
Je suis tout à fait d'accord, PostgreSQL est un mauvais produit, très mal pensé. Et son aspect libre est probablement le défaut le plus rédhibitoire.

Citation Envoyé par SQLpro Voir le message
et des outils délivrés par des éditeurs qui sont pensés à long termes par des équipes dédiées et qui engage la responsabilité de l'éditeur !
Tout à fait, il faut privilégier les grands éditeurs, garants de la qualité. Comme Oracle, qui édite l'excellent MySQL, SGBD plébiscité par les utilisateurs, et surtout pas son immonde clone libre MariaDB.

Citation Envoyé par SQLpro Voir le message
Pour information, certains états de la CEE, autrefois grands supporter du libre, et notamment la suède ou a été conçue MySQL, interdisent dorénavant l'usage de logiciels libre dans l'administration...
Et je suppose que c'est grâce à vous, Professeur. Merci de nous avoir débarrassé de cette lie que représentent les logiciels libres.
4  2 
Avatar de pmaris
Futur Membre du Club https://www.developpez.com
Le 13/02/2019 à 14:19
Excellent,
Jusqu'à la dernière phrase sur la Suède, j'ai cru que c'était du premier degré.
Merci,

Pierre

PS: je raccroche parce que j'attends un appel du support Oracle pour essayer de récupérer une base corrompue.
3  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 13/02/2019 à 15:52
Citation Envoyé par MaximeCh Voir le message
@SQLPro, qui a apporté de superbes contributions au site, continue de s'enfermer dans le cliché de l'initié qui vit du savoir pro-proprio
C'est pas un "cliché" c'est un business.
Si tu es consultant SGBD c'est plus facile de faire passer la douloureuse à 900 euros par jour sur un site IT dispendieux ou ils ont payés à prix d'or des licences Oracle, Sybase ou SQL Server que sur un site de loqueteux ou ils ont installés gratuitement PosgreSQL

Je ferais pareil à sa place, oyez oyez la populace : "Les bases de données ultra chères sont forcément bien mieux sinon elle seraient gratuite", et aussi "les bases de données ultra chères sont ultra performantes, mais vous devez embaucher un expert SGBD pour optimiser de façon adéquate des produits aussi puisant et riches en fonctionnalités" , l'hypnose de masse on sais jamais ça peu marcher...
4  1 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web