Reviers, le 9 décembre 2024
Le commitfest de novembre est en train de se terminer, et je me suis décidé à choisir une nouveauté intégrée à PostgreSQL sur ce commit fest…
Le problème est souvent de choisir la nouveauté à mettre en avant. Pour une fois, je vais me faire plaisir et en choisir une que j’aurais aimé voir arriver beaucoup plus rapidement.
Sommes de contrôle
Les sommes de contrôle sur les fichiers de données ont été ajoutées en version 9.3. Si le DBA les active, ces sommes de contrôle permettent de détecter plus rapidement des corruptions silencieuses. À chaque écriture d’un bloc dans un fichier de données, PostgreSQL calcule une somme de contrôle pour ce bloc. Ce calcul a évidemment un coût en termes de performance, nous y reviendrons plus tard. Il n’y a aucun coût en terme de place disque, la place de la somme de contrôle étant réservée que les sommes soient activées ou non.
À chaque lecture d’un bloc dans un fichier de données, PostgreSQL vérifie que
le bloc correspond bien à sa somme de contrôle. Si la vérification montre un
problème, la requête tombe en erreur, un message explicatif est enregistré
dans les fichiers de traces de PostgreSQL, et la vue système
pg_stat_database voit sa colonne checksums incrémentée. Ainsi, une
solution de supervision peut rapidement remonter une erreur de corruption aux administrateurs,
qui peuvent alors obtenir plus de détails en consultant les fichiers de trace.
À l’époque, nous en parlions lors des audits, mais sans trop insister. L’activation des sommes de contrôle a un impact léger sur les CPU et plutôt fort sur les disques. En effet, cela génère plus de modifications dans les fichiers de données et, par conséquent, sur les journaux de transactions, comme le montrent des discussions en 2019 et un test de Tomas Vondra. De plus, les sommes de contrôle ne sont pas activées par défaut. Donc, les rapports d’audits se contentaient d’indiquer si les sommes de contrôle étaient activées ou non.
Plus tard, nous avons commencé à les recommander et à insister sur leur activation dès que l’application pouvait subir un arrêt assez long (mise à jour applicative complexe, changement de version majeure, etc). Leur activation nous semble actuellement plus intéressante que leur coût.
Le souci
Rapidement, notre souci principal avec les sommes de contrôle est devenu qu’elles ne sont pas utilisées parce qu’elles ne sont pas activées par défaut. Et les activer après création de la base implique de la réécrire intégralement, base arrêtée, ce qui est souvent trop long. C’était même impossible avant PostgreSQL 12.
Un changement intéressant à venir
Nous ne sommes a priori pas les seuls à avoir ce sentiment, et il se trouve que la version 18 va justement changer cela : les sommes de contrôle seront activées par défaut. Nous conservons néanmoins la possibilité de les désactiver si besoin. Un grand merci à Greg Sabino Mullane d’avoir relancé le sujet en août, écrit le patch et poussé à son intégration. Ça va vraiment faciliter la vie des utilisateurs (et des consultants :) ).
Le petit bémol revient à pg_upgrade. Ce dernier ne pourra pas
transformer automatiquement une instance d’une ancienne version sans sommes de
contrôle en instance de nouvelle version avec sommes de contrôle. Donc, si vous
souhaitez utiliser pg_upgrade, il vous faudra avant tout arrêter l’instance
de l’ancienne version et lancer pg_checksums --enable pour activer les sommes de
contrôle, ce qui vous permettra ensuite d’utiliser pg_upgrade. Vous pouvez
aussi utiliser l’ancienne méthode à base d’export et d’import des bases, ou
la méthode plus récente à base de réplication logique. Pour plus
d’informations sur les mises à jour majeures, n’hésitez pas à consulter
notre support de formation « DBA1 - Administration PostgreSQL », voire à
suivre cette formation !
