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

pg_upgrade

pg_upgrade — met à jour une instance du serveur PostgreSQL

Synopsis

pg_upgrade -b ancien_repertoire_executables -B nouveau_repertoire_executables -d ancien_repertoire_donnees -D nouveau_repertoire_donnees [option...]

Description

pg_upgrade (antérieurement connu sous le nom pg_migrator) permet de mettre à jour les fichiers de données vers une version plus récente de PostgreSQL™ sans la sauvegarde et le rechargement de données typiquement requis pour les mises à jour d'une version majeure vers une autre, par exemple d'une version 8.4.7 à la version majeure courante de PostgreSQL™. Il n'est pas nécessaire pour les mises à jour mineures, par exemple de la version 9.0.1 à la version 9.0.4.

Les sorties de version majeures de PostgreSQL ajoutent régulièrement de nouvelles fonctionnalités qui changent souvent la structure des tables système, mais le format interne des données stockées change rarement. pg_upgrade utilise ce fait pour effectuer des mises à jour rapides en créant de nouvelles tables systèmes et en réutilisant les anciens fichiers de données. Si jamais une future version majeure devait modifier le format d'enregistrement des données de telle sorte que l'ancien format des données soit illisible, pg_upgrade ne pourrait pas être utilisé pour ces mises à jour. (La communauté essaiera d'éviter de telles situations.)

pg_upgrade fait de son mieux pour être sûr que la nouvelle et l'ancienne instances soient compatibles au niveau binaire, par exemple en vérifiant que les options de compilation sont compatibles, y compris le format 32/64 bits des binaires. Il est également important que les modules externes soient aussi compatibles au plan binaire, bien que ceci ne puisse être vérifié par pg_upgrade.

pg_upgrade supporte les mises à jour à partir de la version 8.4.X et suivantes jusqu'à la version majeure courante de PostgreSQL™, y compris les images et sorties alpha.

Options

pg_upgrade accepte les arguments de ligne de commande suivants :

-b repertoire_executables, --old-bindir=repertoire_executables

l'ancien répertoire des exécutables PostgreSQL ; variable d'environnement PGBINOLD

-B repertoire_executables, --new-bindir=repertoire_executables

le nouveau répertoire des exécutables PostgreSQL ; variable d'environnement PGBINNEW

-c, --check

uniquement la vérification des instances, ne modifie aucune donnée

-d repertoire_donnees, --old-datadir=repertoire_donnees

répertoire de données de l'ancienne instance ; variable d'environnementPGDATAOLD

-D repertoire_donnees, --new-datadir=repertoire_donnees

répertoire de données de la nouvelle instance ; variable d'environnement PGDATANEW

-j, --jobs

nombres de processus ou threads simultanés à utiliser

-k, --link

utiliser des liens physiques au lieu de copier les fichiers vers la nouvelle instance

-o options, --old-options options

options à passer directement à l'ancienne commande postgres ; les invocations multiples de cette option sont cumulées

-O options, --new-options options

options à passer directement à la nouvelle commande postgres ; les invocations multiples de cette commande sont cumulées

-p port, --old-port=port

le numéro de port de l'ancienne instance ; variable d'environnementPGPORTOLD

-P port, --new-port=port

le numéro de port de la nouvelle instance ; variable d'environnementPGPORTNEW

-r, --retain

conserver les fichiers SQL et de traces y compris après avoir terminé avec succès

-U username, --username=username

nom d'utilisateur de l'instance d'installation ; variable d'environnementPGUSER

-v, --verbose

activer la trace interne verbeuse

-V, --version

afficher les informations de version, puis quitter

-?, --help

afficher l'aide, puis quitter

Usage

Ci-dessous les étapes pour effectuer une mise à jour avec pg_upgrade :

  1. Si nécessaire, déplacez l'ancienne instance

    Si vous utilisez un répertoire d'installation spécifique par version, exemple /opt/PostgreSQL/9.1, vous n'avez pas besoin de déplacer l'ancienne instance. Les installateurs graphiques utilisent tous des répertoires d'installation spécifiques par version.

    Si votre répertoire d'installation n'est pas spécifique par version, par exemple /usr/local/pgsql, il est nécessaire de déplacer le répertoire d'installation courant de PostgreSQL de telle manière à ce qu'il n'interfère pas avec la nouvelle installation de PostgreSQL™. Une fois que le serveur courant PostgreSQL™ est éteint, il est sans danger de renommer le répertoire d'installation de PostgreSQL ; en supposant que l'ancien répertoire est /usr/local/pgsql, vous pouvez faire :

                  mv /usr/local/pgsql /usr/local/pgsql.old

    pour renommer le répertoire.

  2. Pour les installations à partir des sources, construisez la nouvelle version

    Construisez la nouvelle version de PostgreSQL à partir des sources avec des options de configure qui sont compatibles avec l'ancienne instance. pg_upgrade utilisera pg_controldata pour s'assurer que l'ensemble des configurations sont compatibles avant de commencer la mise à jour.

  3. Installez les nouveaux binaires PostgreSQL

    Installez les binaires du nouveau serveur et les fichiers associés. Par défaut, pg_upgrade est inclus dans une installation.

    Pour les installations à partir des sources, si vous souhaitez installer le nouveau serveur dans un répertoire personnalisé, utilisez la variable prefix :

    make prefix=/usr/local/pgsql.new install
    
  4. Initialisez la nouvelle instance PostgreSQL

    Initialisez la nouvelle instance en utilisant la commande initdb. À nouveau, utilisez des options de la commande initdb compatibles avec l'ancienne instance. Beaucoup d'installateurs pré-construits effectuent cette étape automatiquement. Il n'est pas nécessaire de démarrer la nouvelle instance.

  5. Installez les fichiers objets partagés personnalisés

    Installez l'ensemble des fichiers objets partagés personnalisés (ou DLL) utilisés par l'ancienne instance dans la nouvelle instance, par exemple pgcrypto.so, qu'ils soient tirés de contrib ou d'autres sources. N'installez pas les définitions des schémas, par exemple CREATE EXTENSION pgcrypto, car ceux-ci seront mis à jour à partir de l'ancienne instance. Aussi, tous les fichiers de recherche plein texte personnalisés (dictionnaires, synonymes, thésaurus, termes courants) doivent être copiés vers la nouvelle instance.

  6. Ajuster l'authentification

    pg_upgrade se connectera à l'ancien et au nouveau serveur plusieurs fois, aussi vous pourriez avoir besoin de positionner l'authentification sur peer ou d'utiliser un fichier ~/.pgpass (voir Section 32.15, « Fichier de mots de passe »).

  7. Arrêtez les deux serveurs

    Assurez vous que les deux serveurs sont arrêtés en utilisant, sur Unix par exemple :

    pg_ctl -D /opt/PostgreSQL/8.4 stop
    pg_ctl -D /opt/PostgreSQL/9.0 stop
    

    ou sur Windows, en utilisant les noms de services corrects :

    NET STOP postgresql-8.4
    NET STOP postgresql-9.0
    

    Les serveurs standby par réplication en flux et par copie des journaux peuvent rester en fonctionnement jusqu'à une étape ultérieure.

  8. Préparez la mise à jour d'un serveur standby

    Si vous mettez à jour des serveurs standbys (comme indiqué dans la section Étape 10), vérifiez que les anciens serveurs standby sont à jour en utilisant pg_controldata sur l'ancien serveur primaire et l'ancien serveur standby. Vérifiez que les valeurs « Latest checkpoint location » sont identiques sur tous les serveurs. (Il y aura une différence si les anciens serveurs standbys ont été arrêtés avant l'ancien serveur primaire.)

    De plus, en cas de mise à jour des serveurs standbys, modifiez le paramètre wal_level dans le fichier postgresql.conf sur la nouvelle instance maître pour que sa valeur corresponde à celle utilisée sur l'ancienne instance.

  9. Lancez pg_upgrade

    Lancez toujours le binaire pg_upgrade du nouveau serveur, pas celui de l'ancien. pg_upgrade exige la spécification des anciens et des nouveaux répertoires de données et des exécutables (bin). Vous pouvez aussi indiquer des valeurs pour les utilisateurs et les ports, et si vous voulez que les données soient liées plutôt que copiées (par défaut ce dernier).

    Si vous utilisez le mode lien, la mise à jour sera beaucoup plus rapide (pas de copie de fichiers) et utilisera moins d'espace disque, mais vous ne serez plus en mesure d'accèder à votre ancienne instance une fois que la nouvelle instance sera démarrée après la mise à jour. Le mode lien exige également que le répertoire de données de l'ancienne et de la nouvelle instance soient dans le même système de fichiers. (Les tablespaces et pg_xlog peuvent être sur des systèmes de fichiers différents.) Voir pg_upgrade --help pour une liste complète des options.

    L'option --jobs permet l'utilisation de plusieurs cœurs CPU pour copier ou lier des fichiers, et pour sauvegarder et recharger les schémas des bases de données en parallèle ; un bon chiffre pour commencer est le maximum du nombre de cœurs CPU et des tablespaces. Cette option peut réduire dramatiquement le temps pour mettre à jour un serveur avec plusieurs bases de données s'exécutant sur une machine multiprocesseur.

    Pour les utilisateurs Windows, vous devez être connecté avec un compte administrateur, et lancer un shell sous l'utilisateur postgres en positionnant le chemin correct :

    RUNAS /USER:postgres "CMD.EXE"
    SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.0\bin;
    

    puis lancez pg_upgrade avec les répertoires entre guillemets, par exemple :

    pg_upgrade.exe
            --old-datadir "C:/Program Files/PostgreSQL/8.4/data"
            --new-datadir "C:/Program Files/PostgreSQL/9.0/data"
            --old-bindir "C:/Program Files/PostgreSQL/8.4/bin"
            --new-bindir "C:/Program Files/PostgreSQL/9.0/bin"
    

    Une fois démarré, pg_upgrade vérifiera que les deux instances sont compatibles avant d'effectuer la mise à jour. Vous pouvez utiliser pg_upgrade --check pour effectuer uniquement la vérification, y compris si l'ancien serveur est actuellement en fonctionnement. pg_upgrade --check mettra également en évidence les ajustements manuels nécessaires que vous aurez besoin de faire après la mise à jour. Si vous désirez utiliser le mode lien, vous devriez indiquer l'option --link avec l'option --check pour activer les vérifications spécifiques au mode lien. pg_upgrade doit avoir le droit d'écrire dans le répertoire courant.

    Évidemment, personne ne doit accèder aux instances pendant la mise à jour. pg_upgrade lance par défaut les serveurs sur le port 50432 pour éviter les connexions non désirées de clients. Vous pouvez utilisez le même numéro de port pour les deux instances lors d'une mise à jour car l'ancienne et la nouvelle instance ne fonctionneront pas en même temps. Cependant, lors de la vérification d'un ancien serveur en fonctionnement, l'ancien et le nouveau numéros de port doivent être différents.

    Si une erreur survient lors de la restauration du schéma de la base de données, pg_upgrade quittera et vous devrez revenir à l'ancienne instance comme décrit ci-dessous (Étape 16). Pour réessayer pg_upgrade, vous aurez besoin de modifier l'ancienne instance de telle manière que la restauration du schéma par pg_upgrade réussisse. Si le problème est un module contrib, vous pourriez avoir besoin de désinstaller le module contrib de l'ancienne instance et le réinstaller dans la nouvelle instance après la mise à jour, en supposant que le module n'est pas utilisé pour stocker des données utilisateur.

  10. Mettez à jour les serveurs standby par réplication en flux et copie de journaux

    Si vous avez des serveurs standby par réplication continue (voir Section 26.2.5, « Streaming Replication ») ou par copie des journaux de transactions (voir Section 26.2, « Serveurs de Standby par transfert de journaux »), suivez les étapes ci-dessous pour les mettre à jour. Vous ne lancerez pas pg_upgrade sur les serveurs standby, mais plutôt rsync. Ne démarrez encore aucun serveurs.

    1. Installez les nouveaux binaires PostgreSQL sur les serveurs standy

      Assurez-vous que les nouveaux binaires et fichiers de support sont installés sur tous les serveurs standby.

    2. Assurez vous que les nouveaux répertoires de données sur les serveurs standby n'existent pas

      Assurez vous que les nouveaux répertoires de données sur les serveurs standby n'existent pas ou sont vides. Si initdb a été lancé, détruisez les répertoires de données des serveurs standby.

    3. Installez les fichiers objets partagés personnalisés

      Installez les mêmes fichiers objets partagés personnalisés sur les nouveaux serveurs standby que vous avez installé sur la nouvelle instance maître.

    4. Arrêtez les serveurs standby

      Si les serveurs standby sont encore lancés, arrêtez les maintenant en utilisant les instructions ci-dessus.

    5. Sauvegardez les fichiers de configuration

      Sauvegardez tous les fichiers de configuration des serveurs standby que vous avez besoin de conserver, par exemple postgresql.conf, recovery.conf, dans la mesure où ceux-ci seront réécrits ou supprimés dans l'étape suivante.

    6. Lancez rsync

      À partir d'un répertoire qui est au-dessus du répertoire de l'ancienne et de la nouvelle instances, lancez ceci pour chaque esclave :

      rsync --archive --delete --hard-links --size-only ancien_pgdata nouveau_pgdata repertoire_distant
      

      ancien_pgdata et nouveau_pgdata sont relatifs au répertoire courant, et repertoire_distant est au-dessus des ancien et nouveau répertoires des instances sur le serveur standby. Les anciens et nouveaux chemins relatifs doivent correspondre sur le serveur maître et le serveur standby. Consultez les pages du manuel de rsync pour des détails sur la manière de spécifier le répertoire distant, parexemple hotestandby:/opt/PostgreSQL. rsync sera rapide lorsque l'option --link de pg_upgrade est utilisée car il créera des liens physiques sur le serveur distant plutôt que de transférer les données utilisateur. Malheureusement, rsync copie les fichiers associés aux tables temporaires et aux tables non journalisées alors que ce n'est pas utile.

      Si vous avez des tablespaces, vous aurez besoin de lancer une commande rsync similaire pour chaque répertoire de tablespace. Si vous avez déplacé pg_xlog en dehors des répertoires de données, rsync doit être lancé aussi sur ces répertoires.

    7. Configurez les serveurs standby par réplication en flux et par copie de fichiers

      Configurez les serveurs pour les copies des fichiers de transactions. (Vous n'avez pas besoin d'exécuter les fonctions pg_start_backup() et pg_stop_backup() ou effectuer une sauvegarde des fichiers car les esclaves sont toujours synchronisés avec le maître.)

  11. Restaurez pg_hba.conf

    Si vous avez modifié pg_hba.conf, restaurez cette configuration d'origine. Il peut être aussi nécessaire d'ajuster d'autres fichiers de configuration dans la nouvelle instance pour correspondre à l'ancienne instance, par exemple postgresql.conf.

  12. Démarrez le nouveau serveur

    Le nouveau serveur peut maintenant être démarré en toute sécurité, puis les autres serveurs standby synchronisés avec rsync.

  13. Traitements après mise à jour

    Si des traitements après mise à jour sont nécessaires, pg_upgrade affichera des avertissements lors de son travail. Il générera également des scripts qui devront être lancés par l'administrateur. Les scripts se connecteront à chaque base de données qui ont besoin de traitements après mise à jour. Chaque script devrait être lancé comme suit :

    psql --username postgres --file script.sql postgres
    

    Les scripts peuvvent être lancés dans n'importe quel ordre et détruits une fois terminés.

    [Attention]

    Attention

    Généralement, il n'est pas sûr d'accèder des tables référencées dans les scripts de reconstruction avant la fin de leurs traitements ; le faire pourrait entraîner des résultats incorrects ou de médiocres performances. Les tables non référencées dans les scripts de reconstruction peuvent être accédées immédiatement.

  14. Statistiques

    Parce que les statistiques de l'optimiseur ne sont pas tranférées par pg_upgrade, vous serez invités à lancer une commande pour regénérer les statistiques à la fin de la mise à jour. Vous pourriez avoir besoin de positionner les paramètres de connexion pour qu'ils correspondent à votre nouvelle instance.

  15. Détruire les anciennes instances

    Une fois que vous êtes satisfait de la mise à jour, vous pouvez détruire les répertoires de données des anciennes instances en lançant le script indiqué par pg_upgrade à la fin de son traitement. (La destruction automatique n'est pas possible si vous avez défini des tablespaces personnalisés dans l'ancien répertoire de données.) Vous pouvez également supprimer les anciens répertoires d'installation (par exemple bin, share).

  16. Revenir à l'ancienne instance

    Si, après avoir lancé pg_upgrade, vous désirez revenir à l'ancienne instance, il y a plusieurs options :

    • Si vous avez lancé pg_upgrade avec l'option --check, aucune modification n'a été faite à l'ancienne instance et vous pouvez la réutiliser à tout moment.

    • Si vous avez lancé pg_upgrade avec l'option --link, les fichiers de données sont partagés par l'ancienne et la nouvelle instances. Si vous avez démarré la nouvelle instance, le nouveau serveur a écrit dans ces fichiers partagés et il n'est pas sain d'utiliser l'ancienne instance.

    • Si vous avez lancé pg_upgrade sans l'option --link ou n'avez pas encore démarré le nouveau serveur, l'ancienne instance n'a pas été modifiée excepté, si la liaison a commencé, un suffixe .old a été ajouté à $PGDATA/global/pg_control. Pour réutiliser l'ancienne instance, supprimez l'éventuel suffixe .old du fichier $PGDATA/global/pg_control ; vous pouvez alors redémarrer l'ancienne instance.

Notes

pg_upgrade ne supporte pas la mise à jour des bases de données contenant des types de données reg* suivant référençant des OID : regproc, regprocedure, regoper, regoperator, regconfig et regdictionary. Par contre, une donnée de type regtype peut être mis à jour.

Tous les échecs, reconstructions et réindexations seront reportés par pg_upgrade s'ils affectent votre installation ; les scripts d'après mise à jour pour reconstruire les tables et index seront générés automatiquement. Si vous essayez d'automatiser la mise à jour de plusieurs instances, vous devriez constater que les instances avec des schémas de bases de données identiques ont besoin des mêmes étapes après mise à jour ; car les étapes après mise à jour sont basées sur les schémas des bases de données, et pas sur les données utilisateurs.

Pour les déploiements de tests, créez uniquement une copie du schéma de l'ancienne instance, insérez des données de tests, et faites la mise à jour.

Si vous effectuez la mise à jour d'une instance PostgreSQL™ avant la version 9.2 qui utilise un répertoire contenant uniquement un fichier de configuration, vous devez indiquer l'emplacement réel du répertoire de données à pg_upgrade, et indiquer l'emplacement du répertoire de configuration du serveur, exemple -d /repertoire_donnees_reel -o '-D /repertoire_configuration'.

Si vous utilisez un ancien serveur avec une version antérieure à la 9.1 qui utilise un répertoire de socket unix qui n'est pas celui par défaut ou un emplacement par défaut qui est différent de celui de la nouvelle instance, positionnez PGHOST pour qu'il pointe sur la socket de l'ancien serveur. (Ceci n'est pas applicable sous Windows.)

Si vous souhaitez utiliser le mode lien et ne voulez pas que votre ancienne instance ne soit modifiée lorsque la nouvelle instance est démarré, faites une copie de l'ancienne instance et faites la mise à jour à partir de cette copie. Pour faire une copie valide de l'ancienne instance, utilisez rsync pour effectuer une copie grossière de l'ancienne instance lancée, puis arrêtez l'ancien serveur et lancez rsync --checksum à nouveau pour mettre à jour la copie dans un état cohérent avec tous les changements. (L'option --checksum est nécessaire car rsync n'a une granularité sur les dates de modification de fichiers que d'une seconde.) Vous pourriez souhaiter exclure certains fichiers, par exemple postmaster.pid, comme documenté à Section 25.3.3, « Effectuer une sauvegarde de base avec l'API bas niveau ». Si votre système de fichiers supporte les images de système de fichiers ou la fontionnalité Copy-On-Write, vous pouvez utiliser ces fonctionnalités pour faire une sauvegarde de l'ancienne instance et des tablespaces, bien que l'image et les copies doivent être créées simultanément ou lorsque le serveur de bases de données est éteint.