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™ du code source.
Les versions majeures de PostgreSQL™ sont représentées par les deux premiers nombres dans le numéro de version, par exemple 8.4. Les versions mineures sont représentées par le troisième groupe. Par exemple, la 8.4.2 est la deuxième version mineure de la version majeure 8.4. Les versions mineures ne modifient jamais le format de stockage interne et sont toujours compatibles avec les versions mineures antérieures et ultérieures de la même version majeure. Autrement dit, la version 8.4.2 est compatible avec les versions 8.4, 8.4.1 et 8.4.6. Pour mettre à jour entre des versions compatibles, vous devez simplement remplacer les exécutables quand le serveur est arrêté, puis redémarré le serveur. Le répertoire des données reste inchangé -- les mises à jour de versions mineures sont aussi simples que ça.
Pour les versions majeures de PostgreSQL™, le format de stockage interne des données est sujet à modification, ceci compliquant les mises à jour. La méthode traditionnelle pour déplacer les données vers une nouvelle version majeure est de sauvegarder puis de recharger la base de données. Sinon, des possibilités moins bien testées sont disponibles, comme indiqué ci-dessous.
Les nouvelles versions majeures introduisent aussi typiquement quelques incompatibilités visibles par les utilisateurs, donc des modifications des applications pourraient se révéler nécessaires. Les utilisateurs consciencieux voudront tester les applications sur la nouvelle version avant de basculer complètement ; du coup, il est souvent préférable de configurer des installations parallèles des ancienne et nouvelle version. Lors du test d'une mise à jour majeure de PostgreSQL™, réfléchissez aux catégories suivantes de modifications possibles :
Les capacités disponibles pour la suveillance et le contrôle du serveur par les administrateurs s'améliorent de version en version.
Cela inclut typiquement les nouvelles commandes SQL et non pas les modifications de comportement, sauf mention explicite dans les notes de versions.
Habituellement, les bibliothèques comme libpq ne font qu'ajouter de nouvelles fonctionnalités. Sauf, encore une fois, mention explicite dans les notes de versions.
Les modifications du catalogue système n'affectent habituellement que les outils d'administration de bases de données.
Ceci concerne les modifications dans l'API des fonctions du serveur, qui est écrit en langage C. De telles modifications affectent le code qui référencent les fonctions internes du serveur.
Pour sauvegarder des données à partir d'une version majeure de PostgreSQL™ dans le but de les recharger dans une autre, vous devez utiliser pg_dump ; les méthodes au niveau système de fichiers ne fonctionneront pas. Il existe des vérifications mises en place pour vous empêcher d'utiliser un répertoire des données avec une version incompatible de PostgreSQL™, donc aucun dommage ne pourra être fait sur un répertoire de données si un utilisateur essaie d'y lancer un serveur d'une autre version.)
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 19, Authentification du client informe sur la façon d'interdire l'accès.
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 l'ancien 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 # Renommer tous les répertoires des tablespaces cd ~/postgresql-9.0.13 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, Configuration du serveur et mise en place. Les instructions d'installation donnent des conseils sur les endroits stratégiques pour réaliser ces opérations.
![[Note]](images/note.png)
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 tant que tous les sous-répertoires contenant des fichiers installées sont déplacés ensemble ; par exemple si /usr/local/postgres/bin/ va dans /usr/local/postgres.old/bin/, alors /usr/local/postgres/share/ doit aller dans /usr/local/postgres.old/share/. Dans les versions antérieures à la 8.0, déplacer une installation comme ceci n'aurait pas fonctionné.)
Le programme contrib program pg_upgrade permet la migration en ligne d'une installation à partir d'une version majeure de PostgreSQL™ vers la suivante. Gardez en tête que cette méthode ne fournit aucun moyen pour exécuter les ancienne et nouvelle version en parallèle. De plus, pg_upgrade est beaucoup moins testé que pg_dump, donc avoir une sauvegarde à jour est très fortement recommandé au cas où l'opération se terminerait mal.
Il est aussi possible d'utiliser certaines méthodes de réplication, comme Slony™, pour créer un deuxième serveur avec la version mise à jour de PostgreSQL™. L'esclave en question peut être sur le même ordinateur ou sur un ordinateur différent. Une fois qu'il est synchronisé avec le serveur maître (utilisant toujours l'ancienne version de PostgreSQL™), vous pouvez basculer le maître et arrêter l'ancienne instance. Ce type de bascule met généralement quelques secondes seulement pour s'exécuter.
Archivage continu et récupération d'un
instantané (PITR)
