Au-delà de Linux® From Scratch (édition systemd) - Version 11.3

Chapitre 22. Bases de données

Notes importantes sur la mise à jour du serveur de bases de données

[Note]

Note

Cette section parle de la réinstallation des logiciels de bases de données lorsqu'une base de données est utilisée. Elle n'est pas pertinente pour l'installation initiale ou si vous n'avez pas de bases de données pour le paquet mis à jour, mais vous devriez lire cette section pour prendre connaissance des problèmes qui peuvent survenir dans le futur.

Commençons ce chapitre avec une copie d'écran parlante d'un problème qui a vraiment eu lieu. Ce problème n'aura pas lieu si vous installez le logiciel pour la première fois : 

$ sudo systemctl status postgresql
-- postgresql.service - PostgreSQL database server
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2021-10-26 17:11:53 CDT; 2min 49s ago
    Process: 17336 ExecStart=/usr/bin/pg_ctl -s -D ${PGROOT}/data start -w -t 120 (code=exited, status=1/FAILURE)
        CPU: 7ms

Oct 26 17:11:53 SVRNAME systemd[1]: Starting PostgreSQL database server...
Oct 26 17:11:53 SRVNAME postgres[17338]: 2021-10-26 17:11:53.420 CDT [17338] FATAL:
                database files are incompatible with server
Oct 26 17:11:53 SRVNAME postgres[17338]: 2021-10-26 17:11:53.420 CDT [17338] DETAIL:
                The data directory was initialized by PostgreSQL version 13,
                which is not compatible with this version 14.0.
Oct 26 17:11:53 SRVNAME postgres[17336]: pg_ctl: could not start server
Oct 26 17:11:53 SRVNAME postgres[17336]: Examine the log output.
Oct 26 17:11:53 SRVNAME systemd[1]: postgresql.service: Control process exited, code=exited, status=1/FAILURE
Oct 26 17:11:53 SRVNAME systemd[1]: postgresql.service: Failed with result 'exit-code'.
Oct 26 17:11:53 SRVNAME systemd[1]: Failed to start PostgreSQL database server.

Pour éviter ce genre de situation (c.-à-d. où votre serveur de bases de données refuse de démarrer), lisez les réflexions suivantes à propos de la mise à jour d'un DBMS (système de gestion de bases de données).

La cause principale du problème ci-dessus était la mise à jour du serveur vers une nouvelle version majeur et les fichiers de données qui n'ont pas été mis à jour. L'administrateur a réussi à corriger le problème sans perdre de données.

Même si vous effectuez une installation de DBMS initiale, lisez cette section. Elle vous donnera des informations sur la mise en place de sauvegardes et les procédures de restauration (au moins la stratégie pour les créer) suffisantes pour vos besoins et pour la sûreté de vos données.

Mise à jour des paquets de serveurs de bases de données

Les systèmes de bases de données fonctionnent avec des fichiers qui contiennent les métadonnées de la base de données et ses données. La structure interne de ces fichiers est fortement optimisée pour être utilisée par le serveur. Lors de la mise à jour de ce serveur, le nouveau serveur peut s'attendre à un format de fichier différent qde celui utilisé précédemment. Parfois, le nouveau serveur peut utiliser l'ancien format en plus du nouveau—mais sans bénéficier du nouveau format qui peut permettre de meilleures performances. Il se peut aussi que le nouveau serveur reformate les fichiers de données automatiquement au démarrage.

Malheureusement, le cas le plus probable est que le nouveau serveur se plaigne du format obsolète et quitte. Lorsque cela se produit et que vous avez écrasé l'ancien serveur, vous pourriez vous retrouver avec un système cassé et avoir perdu vos données.

Les changements de format de fichiers arrivent en général au changement de versions majeures mais peuvent arriver à d'autres moments. Avant de mettre à jour un serveur de bases de données, vérifiez dans la documentation s'il y a des changements qui nécessitent le reformatage de la base de données.

Bien sur, si vous avez des bases de données dont le contenu n'est pas facile à reconstruire, c'est toujours une bonne idée de créer des sauvegardes de votre base de données de temps en temps. Vous devriez égalememt créer une nouvelle sauvegarde avant la mise à jour du serveur.

Mise à jour par sauvegarde et restauration

[Note]

Note

Une sauvegarde est inutile s'il n'y a pas de processus vérifié pour restaurer les données de la sauvegarde. Lorsque vous utilisez un serveur de bases de données vous devriez non seulement créer des sauvegardes, mais vous devriez vérifier aussi que le processus de restauration fonctionne correctement. Le bon moment pour tester cette procédure est avant que vous ayez besoin de récupérer en urgence des données perdues.

La plupart des serveurs de bases de données fournissent des outils de base pour créer des sauvegardes de vos données. En général les sauvegardes créées avec ces outils peuvent être lues par les nouvelles versions du logiciel (avec un outil de restauration). Utiliser les anciens outils de restauration avec les nouvelles données de sauvegarde est incertain et vous ne devriez jamais supposer aveuglément que cela fonctionnera. C'est possible, mais en général ça ne marche pas.

Le plus simple pour mettre à jour vos fichiers de bases de données est de

  • Créer une sauvegarde complète de votre base de données avec les anciens outils.

    Cette étape crée une copie hors-ligne des fichiers de bases de données pour les utiliser pour l'archivage à long terme, pour la restaurer après une catastrophe ou simplement pour préparer une mise à jour. Cette sauvegarde hors-ligne consiste (1) en une copie complète des fichiers de bases de données ou (2) d'une sauvegarde des fichiers à un certain moment de l'histoire plus toutes les données de journal (c'est la terminologie d'Oracle®, ça s'appelle « Continuous Archiving » ou « write ahead log (WAL) » dans Postgresql) qui contiennent les informations sur les changements de données à partir de ce moment. Ce dernier prend moins de temps à créer si le logiciel de bases de données fournit ce type de journalisation car vous n'avez qu'à sauvegarder les dernier changements après la création de la dernière sauvegarde.

    En terme de mise à jour du serveur, une sauvegarde complète (qui peut être utilisée pour des sauvegardes incrémentales suivantes) est recommandée, mais si la quantité de données est trop élevée, une sauvegarde incrémentale devrait être suffisante. La stratégie appropriée dépend de la quantité de données dans votre base de données (une centaine de lignes ou plusieurs centaines de téraoctets ?). Une sauvegarde complète de cette dernière n'est pas rapide. Pour complètement protéger vos données, créez une sauvegarde des anciens binaires (et/ou leurs sources) et stockez-les avec les fichiers de données pour vous assurer qu'il y a une solution de repli si le nouveau logiciel n'est pas capable de lire les anciennes données.

  • Mettez à jour le serveur

    Pour cette étape, exécutez les instructions de construction du serveur de bases de données telles qu'elles sont montrées dans les sections suivantes parlant de DBMS comme MariaDB ou PostgreSQL. C'est-à-dire, construisez le logiciel comme d'habitude avec les instructions de BLFS.

  • Restaurez la base de données avec les nouveaux outils.

    Pour restaurer les données, vous devriez utiliser les outils du serveur nouvellement installé. Pendant la restauration, les nouveaux outils créeront ou mettront à jour les fichiers de données vers le format requis par le nouveau logiciel. On suppose que celui-ci est capable de lire les anciennes données.

Comme vous avez déjà une procédure de sauvegarde (et que vous avez testé votre procédure de restauration, n'est-ce pas ?), c'est la manière la plus simple de mettre à jour puisque vous utilisez des procédures connues pour mettre à jour comme vous le faites toujours—au moins pour la sauvegarde et la restauration.

Mise à jour des fichiers de bases de données avec des outils systèmes

Certains systèmes de bases de données (par exemple Postgresql) fournissent un outil qui peut reformater (mettre à jour) les fichiers de bases de données existants vers le nouveau format. Si vous devez restaurer vos données à partir d'une sauvegarde (par exemple, l'outil de mise à jour ayant échoué), vous devrez réinstaller l'ancien logiciel pour retrouver vos données.

Même si ces outils peuvent fonctionner comme attendu, vous devriez créer une sauvegarde complète avant de les lancer. Un échec peut occasionner de sérieux dommages à votre base de données.

Remarque pour des DBMS spécifiques

PostgreSQL

Documentation en amont pour la sauvegarde et la restauration : https://www.postgresql.org/docs/current/backup.html

MariaDB

Documentation en amont pour la sauvegarde et la restauration : https://mariadb.com/kb/en/backup-and-restore-overview/

Sqlite

Ne sous-estimez pas Sqlite. C'est un DBMS riche en fonctionnalités. La différence majeure par rapport aux deux grands concurrents plus haut est que Sqlite ne fournit pas d'accès par une API en réseau. Les bases de données Sqlite sont des fichiers stockés sur la même machine que le programme qui l'utilise. La manipulation de données se fait par des appels API vers des bibliothèques directement dans le programme.

Dans la documentation en amont, vous pourriez trouver que ceci est utile :

La documentation de l'outil en ligne de commande sqlite3 : https://www.sqlite.org/cli.html

La documentation des appels API de sauvegarde : https://www.sqlite.org/backup.html

Malheureusement, il n'y a pas de chapitre dédié dans la documentation en amont sur la sauvegarde et la restauration, mais il y a plusieurs articles à ce sujet sur internet. Voici un exemple.

Documentation pour la sauvegarde et la restauration : https://database.guide/backup-sqlite-database/

Berkeley DB

Comme Sqlite ce logiciel agit sur des fichiers de bases de données locaux ce qui signifie qu'il n'y a pas d'interface en réseau.

Les ressources intéressantes pour la sauvegarde et la restauration des bases de données Berkeley sont les pages de manuel de db_dump et de sa contre-partie db_load.