Cette section discute de la façon de migrer les données de la base vers une version plus récente de PostgreSQL™. Le sujet de cette section ne concerne pas la procédure d'installation per se du logiciel ; ces détails sont dans le Chapitre 15, Procédure d'installation de PostgreSQL™.

En règle générale, le format interne des données est sujet à modification d'une version majeure à l'autre (quand le nombre après le premier point change). Ce qui n'est pas le cas pour les versions mineures à l'intérieur d'une même version majeure (quand seul le nombre après le deuxième point change) ; elles ont toujours un format de stockage compatible. Par exemple, les versions 8.1.1, 8.2.3 et 8.3 ne sont pas compatibles, alors que les versions 8.2.3 et 8.2.4 le sont. Lorsque la mise à jour concerne des versions compatibles, les exécutables peuvent simplement être remplacés et le répertoire des données sur le disque réutilisé. Dans le cas contraire, il faut sauvegarder les données et les restaurer sur le nouveau serveur. pg_dump doit être utilisé pour cela ; les méthodes de sauvegarde au niveau système de fichiers ne fonctionnent évidemment pas. Un certain nombre de vérifications est automatiquement effectué pour interdire l'utilisation d'un répertoire de données d'une version incompatible. Il n'y a donc pas grand risque à lancer une mauvaise version de PostgreSQL™ sur un répertoire de données.

Il est recommandé d'utiliser les programmes pg_dump et pg_dumpall issus de la nouvelle version de PostgreSQL™. Ceci permet de tirer parti des améliorations de ces programmes. Les versions actuelles des programmes de sauvegarde peuvent lire des données sur des serveurs de versions anciennes, jusqu'à la 7.0.

La durée d'indisponibilité est minimisée par l'installation de nouveau serveur dans un répertoire différent et par le lancement en parallèle des deux serveurs (ancien et nouveau), sur des ports différents. On peut alors utiliser une commande telle que :

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

pour transférer les données. On peut aussi utiliser un fichier intermédiaire. L'ancien serveur peut alors être éteint, et le nouveau démarré sur le port utilisé par l'ancien. Il est impératif que la base de données ne soit pas modifiée pendant l'exécution de pg_dumpall. Ces modifications seraient, sans cela, perdues. Le Chapitre 21, Authentification du client informe sur la façon d'interdire l'accès.

Il est aussi possible d'utiliser des outils de réplication comme Slony™ pour créer un serveur esclave avec la nouvelle version de PostgreSQL™. L'esclave peut se trouver sur le même ordinateur ou sur un autre. Une fois qu'il est synchronisé avec le serveur maître (utilisant l'ancienne version de PostgreSQL™), le maître et l'esclave peuvent être basculés pour que l'esclave devienne le maître. L'ancien serveur peut alors être arrêté. Ce basculement intervient en quelques secondes dans le cadre d'une mise à jour.

En pratique, on souhaite souvent tester son application sur le nouveau serveur avant de basculer définitivement. C'est une autre raison de configurer des installations concurrentes de l'ancienne et de la nouvelle versions.

Si n'est pas souhaité, ou pas possible, de lancer les deux serveurs en parallèle, il faut réaliser l'étape de sauvegarde avant d'installer la nouvelle version, éteindre le serveur, déplacer l'ancienne version vers 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.3.23
gmake install
initdb -D /usr/local/pgsql/data
postgres -D /usr/local/pgsql/data
psql -f sauvegarde.sql postgres

Toutes les méthodes pour arrêter et démarrer les serveurs, ainsi que d'autres détails sont présentés dans le Chapitre 17, Environnement du système d'exploitation. Les instructions d'installation donnent des conseils sur les endroits stratégiques pour réaliser ces opérations.