Toute mise à jour logicielle présente une part de risques et doit être préparée soigneusement. C'est d'autant plus vrai lorsque que l'on parle de serveur de bases de données. Néanmoins le SGBD open source PostgreSQL se démarque dans ce domaine par sa stabilité et sa souplesse. Voici 5 conseils pour réaliser vos montées de version PostgreSQL en toute sérénité. Par la société Dalibo.

1- La mise à jour est-elle mineure ou majeure ?

La communauté PostgreSQL distingue deux types de montée en version: les mises à jours mineures et majeures.

Les données de votre instance PostgreSQL sont toujours compatibles d'une version mineure à l'autre (par exemple, de la version 9.1.2 à la version 9.1.3). Ainsi, les mises à jour vers une version mineure supérieure peuvent se faire sans migration de données, sauf cas exceptionnel qui serait alors précisé dans les notes de version. Pensez tout de même à faire une sauvegarde préalable par sécurité.

À contrario, si la mise à jour consiste en un changement de version majeure (par exemple de la version 8.4.5 à la version 9.0.1), alors il est nécessaire de s'assurer que les données seront transférées correctement sans incompatibilité.

En effet, le terme mineure/majeure n'indique pas le degré d'urgence mais le niveau de complexité de l'opération. De fait, les mises à jour mineures sont souvent réalisées rapidement car elles sont simples et corrigent des bugs ou des failles de sécurité. À l'inverse, les mises à jour majeures nécessitent plus de préparation.

2- Lire attentivement les notes de version ("Releases Notes")

Chaque nouvelle version de PostgreSQL est accompagnée d'une note expliquant les améliorations, les corrections et les innovations apportées par cette version, qu'elle soit majeure ou mineure. Ces notes contiennent toujours une section dédiée aux mises à jour dans laquelle on trouve des conseils essentiels.

Les « Releases Notes » sont présentes dans l'annexe E de la documentation officielle (http://docs.postgresql.fr/current/release.html).

3- Choisir la bonne méthode

Une mise à jour PostgreSQL peut se faire selon 3 méthodes principales:

La mise à jour par fichiers intermédiaires consiste à sauvegarder les bases avec la commande pg_dump, installer la nouvelle version, créer un nouveau répertoire des données et restaurer les bases avec la commande pg_restore. Cette méthode est la plus simple mais elle entraîne une longue coupure de service;

La mise à jour “sur place” (in-place upgrade) avec l'outil pg_upgrade permet de mettre à jour un serveur PostgreSQL sans déplacer les données. Cette technique peut-être 3 à 10 fois plus rapide qu'une sauvegarde/restauration;

La mise à jour en parallèle nécessite d'installer la nouvelle version de PostgreSQL sans désinstaller l'ancienne, puis faire fonctionner les deux versions en même temps et transférer des données entre les deux instances. Cette méthode est plus complexe mais elle minimise la durée des coupures de service.

Le choix de la méthode va donc dépendre de plusieurs facteurs: les contraintes d'interruption de service, la volumétrie des bases, les ressources matérielles disponibles, etc.

4-Les tests de non-régression

Idéalement lors de la livraison d'un logiciel, l'éditeur délivre également une série de jeux de tests permettant de valider l'environnement de production qui accueillera l'application. Si ce n'est pas le cas deux options s'offrent à vous:

L'outil pgTAP (http://pgtap.org/) permet de réaliser rapidement et simplement une série de jeux de tests pour valider la cohérence de vos bases de données;

Avec pgShark (https://github.com/dalibo/pgshark) vous pouvez enregistrez le trafic SQL envoyé vers le serveur PostgreSQL, puis le “rejouer” sur la nouvelle version pour détecter d'éventuelles erreurs.

En parallèle, il est essentiel de vérifier que le suivi des erreurs et des alertes est bien activé (voir la section “Error Reporting and Logging” dans le fichier de configuration).

5-Tester la procédure de bascule

Quelle que soit la méthode choisie (mise à jour “sur place”, en parallèle ou par fichier intermédiaire), une mise à jour de PostgreSQL reste une opération délicate. Il est essentiel de tester au préalable la montée en version dans un environnement de pré-production. Cela vous donnera une indication sur la durée de l'interruption de service à prévoir et donc des conséquences sur le reste de la pile applicative. En parallèle, vous devrez également préparer une procédure de retour en arrière (“Rollback”) si les tests de régression détectent une anomalie.

Tout ceci demande du temps et une certaine habitude. Pour garder l'esprit tranquille, le meilleur conseil que l'on puisse donner est simple: faites systématiquement toutes les montées en version au fur et à mesure de leurs sorties. La communauté publie une version majeure et environ 4 versions mineures par an. Vous garderez ainsi vos procédures à jour, tout en profitant des toutes dernières améliorations de PostgreSQL.

Dalibo http://www.dalibo.org