IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

17.6. Mise à jour d'une instance PostgreSQL

Cette section concerne la mise à jour des données de votre serveur d'une version de PostgreSQL™ vers une version ultérieure.

Les versions majeures de PostgreSQL™ sont représentées par les deux premiers groupes de chiffres du numéro de version, par exemple 8.4. Les versions mineures de PostgreSQL™ sont représentées par le troisième groupe de chiffres, par exemple 8.4.2 est la deuxième version mineure de la 8.4. Les versions mineures ne modifient jamais le format de stockage interne et sont donc compatibles avec les versions antérieures et ultérieures de la même version majeure. Par exemple, le format 8.4.2 est compatible avec le format des versions 8.4, 8.4.1 et 8.4.6. Pour mettre à jour entre des versions compatibles, vous devez simplement remplacer les binaires une fois le serveur arrêté, puis redémarrer le serveur. Le répertoire des données ne doit pas être modifié. 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, 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. D'autres méthodes sont disponibles, ce qui est expliqué ci-dessous.

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, Notes de version). Soyez particulièrement attentif à la section Migration. Si vous mettez à jour en passant plusieurs versions majeures, assurez-vous de lire les notes de version de chaque version majeure que vous passez.

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 :

Administration

Les fonctionnalités disponibles pour les administrateurs pour surveiller et contrôler le serveur s'améliorent fréquemment à chaque nouvelle version.

SQL

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.

API

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.

Catalogues systèmes

Les modifications dans les catalogues systèmes affectent seulement les outils de gestion des bases de données.

API serveur pour le langage C

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.

17.6.1. Mise à jour des données via pg_dump

Pour sauvegarder les données d'une version majeure de PostgreSQL™ et les recharger dans une autre, vous devez utiliser pg_dump ; 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 7.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.

  1. 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 19, Authentification du client 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
    

    Si vous devez conserver les OID (parce que vous les utilisez en tant que clés étrangères, par exemple), utilisez l'option -o lors de l'exécution de pg_dumpall.

    Pour faire la sauvegarde, vous pouvez utiliser la commande pg_dumpall de la version en cours d'exécution. Néanmoins, pour de meilleurs résultats, essayez d'utiliser la commande pg_dumpall provenant de la version 9.2.4 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.

  2. 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 17, Configuration du serveur et mise en place pour des détails sur le lancement et l'arrêt d'un serveur.

  3. Lors de la restauration de la sauvegarde, renommez ou supprimez l'ancien répertoire d'installation. 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.)

  4. Installez la nouvelle version de PostgreSQL™ comme indiqué dans la section suivante Section 15.4, « Procédure d'installation ».

  5. 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
    
  6. Restaurez vos modifications dans les fichiers pg_hba.conf et postgresql.conf.

  7. 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
    
  8. 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.

17.6.2. Méthodes de mise à jour sans sauvegarde

Le module pg_upgrade permet la migration d'une installation d'une version majeure de PostgreSQL™ à une autre, par modification des fichiers présents. Les mises à jour se réalisent en quelques minutes.

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.