PostgreSQLLa base de données la plus sophistiquée au monde.

23.4. Migration entre les différentes versions

Cette section discute de la façon de migrer vos données de la base à partir d'une version de PostgreSQL™ vers une autre, plus récente. La procédure d'installation du logiciel per se n'est pas le sujet de cette section ; ces détails sont dans le Chapitre 14, Procédure d'installation.

En règle générale, le format interne des données est modifié entre les différentes versions de PostgreSQL™ (quand le nombre après le premier point change). Ceci ne s'applique pas entre les différentes sorties mineures ayant le même numéro de version majeur (quand seul le nombre après le deuxième point change) ; elles ont toujours un format de stockage compatible. Par exemple, les versions 7.0.1, 7.1.2 et 7.2 ne sont pas compatibles, alors que les versions 7.1.1 et 7.1.2 le sont. Lorsque vous mettez à jour entre des versions compatibles, vous pouvez simplement remplacer les exécutables et ré-utiliser le répertoire des données sur le disque. Sinon, vous avez besoin de sauvegarder vos données et de les restaurer sur le nouveau serveur. Ceci doit se faire en utilisant pg_dump ; les méthodes de sauvegarde au niveau système de fichiers ne fonctionneront évidemment pas. Il existe des vérifications en place pour vous empêcher d'utiliser un répertoire de données d'une version incompatible version de PostgreSQL™, donc aucun mal ne sera fait si vous essayez de lancer un serveur d'une mauvaise version dans un répertoire de données.

Il est recommandé d'utiliser les programmes pg_dump et pg_dumpall à partir de la nouvelle version de PostgreSQL™, pour utiliser les avantages de toutes améliorations effectuées sur ces programmes. Les versions actuelles des programmes de sauvegarde peuvent lire des données à partir des serveurs d'anciennes versions, jusqu'à la 7.0.

Vous minimiserez la durée d'indisponibilité en installant le nouveau serveur dans un répertoire différent et en lançant l'ancien et le nouveau serveur en parallèle sur des ports différents, puis en utilisant des commandes comme

pg_dumpall -p 5432 | psql -d postgres -p 6543

pour transférer les données. Ou utilisez un fichier intermédiaire si vous voulez. Vous pouvez alors éteindre le nouveau serveur et démarrer le nouveau sur le port que l'ancien utilisait. Vous devez vous assurer que l'ancienne base de données n'est pas modifiée après que vous ayez lancé pg_dumpall, sans quoi ces modifications seraient évidemment perdues. Référez vous au Chapitre 20, Authentification du client pour savoir comment interdire l'accès.

En pratique, vous voudrez certainement tester votre application sur le nouveau serveur avant de basculer définitivement. C'est une autre raison pour configurer des installations concurrentes avec l'ancienne et la nouvelle version.

Si vous ne pouvez pas ou ne voulez pas lancer les deux serveurs en parallèle, vous pouvez faire l'étape de sauvegarde avant d'installer la nouvelle version, éteindre le serveur, déplacer l'ancienne version à un autre endroit, installer la nouvelle, la démarrer et enfin restaurer les données. Par exemple :

pg_dumpall > sauvegarde.sql
pg_ctl stop
mv /usr/local/pgsql /usr/local/pgsql.old
cd ~/postgresql-8.1.23
gmake install
initdb -D /usr/local/pgsql/data
postmaster -D /usr/local/pgsql/data
psql -f sauvegarde.sql postgres

Vous trouverez les méthodes pour arrêter et démarrer les serveurs, ainsi que d'autres détails dans le Chapitre 16, Environnement du système d'exploitation. Les instructions d'installation vous donneront des conseils sur les endroits stratégiques pour réaliser ces opérations.

[Note]

Note

Quand vous « déplacez l'ancienne version à un autre endroit », l'ancienne installation pourrait ne plus être tout à fait utilisable. Certains des exécutables contiennent les chemins absolus vers les différents programmes et fichiers de données installés. Ceci n'est habituellement pas un gros problème mais si vous planifiez d'utiliser deux installations en parallèle pendant un moment, vous devez leur affecter des répertoires d'installation différents au moment de la construction. (Ce problème est rectifié pour PostgreSQL™ 8.0 et ultérieurs mais vous devez faire bien attention à déplacer les anciennes installations.)