23.5. Migration entre versions
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 14,
Procédure d'installation.
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 7.2.1, 7.3.2 et 7.4
ne sont pas compatibles, alors que les versions 7.2.1 et 7.2.2 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 sont
automatiquement effectuées 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 20,
Authentification du client informe sur la façon d'interdire
l'accès.
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.2.5
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 16,
Environnement du système d'exploitation. Les instructions
d'installation donnent des conseils sur les endroits stratégiques
pour réaliser ces opérations.
Note
Lorsque « l'ancienne installation est
déplacée », il se peut qu'elle ne soit plus
correctement utilisable. En effet, certains exécutables
contiennent des chemins absolus vers les différents programmes et
fichiers de données installés. Ce n'est habituellement pas un
problème insurmontable, mais pour utiliser deux installations en
parallèle pendant un moment, il faut leur affecter des
répertoires d'installation différents au moment de la
construction. (Ce problème est rectifié pour PostgreSQL™ 8.0 et suivantes mais une
attention particulière doit être portée au déplacement de
versions plus anciennes.)