Cette section concerne la mise à jour des données de votre serveur d'une version de PostgreSQL vers une version ultérieure.
Les numéros de versions actuelles de PostgreSQL se composent d'un numéro de version majeure et mineure. Par exemple, pour le numéro de version 10.1, 10 est le numéro de la version majeure et 1 est le numéro de la version mineure, ce qui signifie que c'est la première mise à jour mineure de la version majeure 10. Pour les versions précédant PostgreSQL 10.0, la numérotation des versions est composée de 3 numéros, par exemple 9.5.3. Dans ces cas, la version majeure est composée des deux premiers groupes de chiffres du numéro de version, par exemple 9.5, et la version mineure est le troisième chiffre, par exemple 3, signifiant que c'est la troisième version mineure de la version majeure 9.5.
Les versions mineures ne changent jamais le format de stockage interne et sont toujours compatibles avec les versions mineures précédentes et suivantes de la même version majeure. Par exemple, la version 10.1 est compatible avec la version 10.0 et la version 10.6. De même, par exemple, la version 9.5.3 est compatible avec 9.5.0, 9.5.1 et 9.5.6. Pour mettre à jour entre versions compatibles, il suffit de remplacer les exécutables lorsque le serveur est arrêté et de redémarrer le serveur. Le répertoire de données reste inchangé : les mises à jour mineures sont aussi simples que cela.
Pour les versions majeures de PostgreSQL, le format de stockage interne des données est sujet à modification, ce qui complique les mises à jour. La méthode traditionnelle de migration des données vers une nouvelle version majeure est de sauvegarder puis recharger la base de données, même si cela peut être lent. pg_upgrade est une méthode plus rapide. Des méthodes de réplication sont aussi disponibles, comme discuté ci-dessus.
De plus, les nouvelles versions majeures introduisent généralement des incompatibilités qui impactent les utilisateurs. Du coup, des modifications peuvent être nécessaires sur les applications clientes. Tous les changements visibles par les utilisateurs sont listés dans les notes de version (Annexe E). Soyez particulièrement attentif à la section Migration. Bien que vous pouvez mettre à jour d'une version majeure vers une autre sans passer par les versions intermédiaires, vous devez lire les notes de version de toutes les versions majeures intermédiaires.
Les utilisateurs précautionneux testeront leur applications clientes sur la nouvelle version avant de basculer complètement. Du coup, il est souvent intéressant de mettre en place des installations parallèles des ancienne et nouvelle versions. Lors d'un test d'une mise à jour majeure de PostgreSQL, pensez aux différentes catégories suivantes :
Les fonctionnalités disponibles pour les administrateurs pour surveiller et contrôler le serveur s'améliorent fréquemment à chaque nouvelle version.
Cela inclut généralement les nouvelles commandes ou clauses SQL, et non pas des changements de comportement sauf si c'est spécifiquement précisé dans les notes de version.
Les bibliothèques comme libpq se voient seulement ajouter de nouvelles fonctionnalités, sauf encore une fois si le contraire est mentionné dans les notes de version.
Les modifications dans les catalogues systèmes affectent seulement les outils de gestion des bases de données.
Ceci implique des modifications dans l'API des fonctions du moteur qui est écrit en C. De telles modifications affectent le code qui fait référence à des fonctions du moteur.
Une méthode de mise à jour revient à sauvegarder les données d'une version majeure de PostgreSQL et de la recharger dans une autre -- pour cela, vous devez utiliser un outil de sauvegarde logique comme pg_dumpall ; une sauvegarde au niveau système de fichiers ne fonctionnera pas. Des vérifications sont faites pour vous empêcher d'utiliser un répertoire de données avec une version incompatible de PostgreSQL, donc aucun mal ne sera fait si vous essayez de lancer un serveur d'une version majeure sur un répertoire de données créé par une autre version majeure.)
Il est recommandé d'utiliser les programmes pg_dump et pg_dumpall provenant de la nouvelle version de PostgreSQL, pour bénéficier des améliorations apportées à ces programmes. Les versions actuelles de ces programmes peuvent lire des données provenant de tout serveur dont la version est supérieure ou égale à la 8.0.
Ces instructions supposent que votre installation existante se
trouve dans le répertoire /usr/local/pgsql et
que le répertoire des données est
/usr/local/pgsql/data. Remplacez ces chemins
pour correspondre à votre installation.
Si vous faites une sauvegarde, assurez-vous que votre base de
données n'est pas en cours de modification. Cela n'affectera pas
l'intégrité de la sauvegarde mais les données modifiées ne seront
évidemment pas incluses. Si nécessaire, modifiez les droits dans
le fichier /usr/local/pgsql/data/pg_hba.conf
(ou équivalent) pour interdire l'accès à tout le monde sauf vous.
Voir Chapitre 20 pour plus
d'informations sur le contrôle des accès.
Pour sauvegarder votre installation, exécutez la commande suivante :
pg_dumpall > fichier_en_sortie
Pour faire la sauvegarde, vous pouvez utiliser la commande pg_dumpall de la version en cours d'exécution ; voir Section 25.1.2 pour plus de détails. Néanmoins, pour de meilleurs résultats, essayez d'utiliser la commande pg_dumpall provenant de la version 10.23 de PostgreSQL, car cette version contient des corrections de bugs et des améliorations par rapport aux anciennes version. Bien que ce conseil peut sembler étonnant, étant donné que vous n'avez pas encore été la nouvelle version, il est conseillé de le suivre si vous souhaitez installer la nouvelle version en parallèle de l'ancienne. Dans ce cas, vous pouvez terminer l'installation normalement et transférer les données plus tard. Cela diminuera aussi le temps d'immobilisation.
Arrêtez l'ancien serveur :
pg_ctl stop
Sur les systèmes qui lancent PostgreSQL au démarrage, il existe probablement un script de démarrage qui fera la même chose. Par exemple, sur un système Red Hat Linux, cette commande pourrait fonctionner :
/etc/rc.d/init.d/postgresql stop
Voir Chapitre 18 pour des détails sur le lancement et l'arrêt d'un serveur.
Lors de la restauration de la sauvegarde, renommez ou supprimez l'ancien répertoire d'installation si ce n'est pas spécifique à la version. Il est préférable de le renommer car, en cas de problème, vous pourrez le récupérer. Garder en tête que le répertoire peut prendre beaucoup d'espace disque. Pour renommer le répertoire, utilisez une commande comme celle-ci :
mv /usr/local/pgsql /usr/local/pgsql.old
(Assurez-vous de déplacer le répertoire en un seul coup, pour que les chemins relatifs restent inchangés.)
Installez la nouvelle version de PostgreSQL comme indiqué dans la section suivante Section 16.4.
Créez une nouvelle instance de bases de données si nécessaire. Rappelez-vous que vous devez exécuter ces commandes une fois connecté en tant que l'utilisateur de bases de données (que vous devez déjà avoir si vous faites une mise à jour).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Restaurez vos modifications dans les fichiers
pg_hba.conf et
postgresql.conf.
Démarrez le serveur de bases de données, en utilisant encore une fois l'utilisateur de bases de données :
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Enfin, restaurez vos données à partir de votre sauvegarde :
/usr/local/pgsql/bin/psql -d postgres -f outputfile
en utilisant le nouveau psql.
Il est possible de parvenir à une immobilisation moins longue en installant le nouveau serveur dans un autre répertoire et en exécutant l'ancien et le nouveau serveur, en parallèle, sur des ports différents. Vous pouvez ensuite utiliser quelque chose comme :
pg_dumpall -p 5432 | psql -d postgres -p 5433
pour transférer vos données.
Le module pg_upgrade permet la mise à jour en ligne
d'une installation d'une version majeure de
PostgreSQL vers une autre. Les mises à jour se
sont en quelques minutes, notamment avec le mode --link.
Il requiert les mêmes étapes que pour pg_dumpall
ci-dessus, autrement dit lancer/arrêter le serveur, lancer
initdb. La documentation de pg_upgrade
surligne les étapes nécessaires.
Il est aussi possible d'utiliser certaines méthodes de réplication, comme Slony, pour créer un serveur esclave avec la version à jour de PostgreSQL. Ceci est possible car Slony permet une réplication entre des versions majeures différentes de PostgreSQL. L'esclave peut se trouver sur le même serveur ou sur un autre. Une fois qu'il est synchronisé avec le serveur maître (qui utilise toujours l'ancienne version de PostgreSQL), vous pouvez basculer le serveur maître sur le nouveau serveur et arrêter l'ancien maître. Ce type de bascule fait que l'arrêt requis pour la mise à jour se mesure seulement en secondes.