Parmi les drames universellement reconnus, les corruptions de données sont des
événements mécaniques ou logiques qui surviennent à des moments imprévisibles.
Tantôt il s’agira de l’âge avancé des secteurs disques, tantôt il s’agira d’une
extinction inopinée d’un composant électrique ou d’une perte de paquet dans les
protocoles de cache.
Bien que peu de personnes peuvent se vanter d’en avoir observé au cours de leur
carrière, les corruptions sont particulièrement dévastatrices lorsqu’elles se
sont propagées sur les supports de sauvegardes et détectées bien des jours, voire
des semaines après l’incident. Les moteurs de bases de données sont très résilients
face à ces destructions de données, en proposant des mécanismes de journalisation
adaptés. Malgré cela, des précautions sont de mises.
Jusqu’à très récemment, je ne me préoccupais pas de la pertinence de mes
sauvegardes de fichiers personnels réalisées naïvement avec un script rsync.
C’est honteux dans nos métiers, mais l’adage du cordonnier s’est vérifié avec
moi lors de l’exécution d’un vulgaire find $NOVAR/ -delete durant des tests.
Après cet épisode et l’amertume d’avoir perdu quelques travaux, ou la surprise
de découvrir les ravages de leur disparition plusieurs semaines après ma fatale
erreur, je me suis tourné vers l’outil incontournable dont tous mes collègues me
parlaient : BorgBackup
Depuis plusieurs semaines, j’étudie les nouveautés de la prochaine version majeure
de PostgreSQL avec un intérêt grandissant pour le connecteur postgres_fdw.
Cette extension assez folle n’a pas son équivalent sur les autres systèmes de
bases de données du marché, et pour cause, PostgreSQL est l’un des rares à respecter
la norme SQL/MED, sous-partie du langage SQL tel que défini par le standard
ISO/IEC 9075-9.
Ce mois-ci, je vous propose de réviser un peu le langage SQL en l’appliquant pour
des cas d’usage assez fréquents qui mettent en scène des types temporels, notamment
les intervalles de dates. Ce sera l’occasion également de revenir sur l’implémentation
très originale qu’en a fait PostgreSQL avec les types d’intervalle de valeurs, ou
range types dans la documentation.
Le partitionnement déclaratif a été une véritable révolution à la sortie de la
version 10 de PostgreSQL en octobre 2017. La gestion des sous-tables devenait
alors bien plus aisée au quotidien, simplifiant leur mise en place et leur
maintenance.
Sans cesse amélioré au cours des dernières années, je me souviens encore de mon
émerveillement devant la magie du partitionnement par hachage, apparu en
version 11. Comment le déployer et que permet-il ? J’ai voulu m’en rendre compte
dans une rapide démonstration sur le type UUID en étudiant les fonctions
d’appui qui se cachent derrière le hachage des valeurs.