Il existe essentiellement trois façons de mettre à niveau PostgreSQL à partir de différentes versions principales (par exemple, 9.1 à 9.3).
Mise à niveau avec pg_dump
Le premier, et recommandé si possible, est de faire un vidage de l'ancienne version (9.1) en utilisant le binaire de la version la plus récente (9.3) et de le restaurer sur un nouveau cluster créé de la version la plus récente.
Cette approche est, en général, la plus lente, mais aussi la plus réalisable. Une astuce pour accélérer le processus consiste à utiliser la concurrence. Pour effectuer un vidage avec des travaux parallèles, vous pouvez effectuer:
$ pg_dump --format=directory --jobs=4 --no-synchronized-snapshots --file=/path/to/mydump mydatabase
Vous devrez le faire pour chaque base de données que vous avez, ajuster la --jobs=4valeur à n'importe quelle valeur (tester certaines valeurs de 2 au nombre de cœurs et voir ce qui donne une meilleure vitesse). De plus, pendant cette phase, personne ne doit être connecté à la base de données, toute modification entraînera un vidage corrompu (en raison de l'option non sécurisée --no-synchronized-snapshots).
Après cela, vous pouvez restaurer votre vidage dans la nouvelle instance en utilisant pg_restore:
$ createdb <options> -T template0 mydatabase
$ pg_restore --exit-on-error --jobs=4 --dbname=mydatabase /path/to/mydump
Après cela, il est recommandé d'exécuter ANALYZEsur votre base de données:
$ vacuumdb --analyze-only mydatabase
(si vous pouvez vous permettre le temps, exécuter uniquement --analyzeaussi VACUUMla base de données et mettre à jour la visibilité MAPS)
Mise à niveau avec pg_upgrade
Une autre option consiste à utiliser la contribpg_upgrade . En utilisant la --linkméthode, il fournit un moyen très rapide de mettre à niveau PostgreSQL.
Avant de l'utiliser, vous devez faire une sauvegarde de l'ensemble du répertoire de données, car en --linkmode, si quelque chose ne va pas, vous pouvez perdre les deux données (nouvelles et anciennes). Lisez également l'intégralité de la documentation et en particulier les notes en bas (il existe certaines limitations pour pg_upgrade).
MISE À JOUR: Veuillez utiliser l' --checkoption avant d'exécuter la commande définitive. En outre, pour les grandes bases de données, il est recommandé d'exécuter cette commande dans une session d'écran.
Mettre à niveau à l'aide d'un outil de réplication basé sur un déclencheur
Une autre option pour mettre à niveau une version consiste à utiliser un outil de réplication basé sur le déclencheur. Comme Slony, Bucardo et Londiste.
C'est l'option qui nécessite le moins de temps d'arrêt possible, mais c'est la plus difficile à travailler.
Pour ce faire, vous devez créer un maître-esclave où le maître est votre version actuelle (9.1) et l'esclave est la nouvelle version (9.3). Vous devez ensuite attendre la première synchronisation (avec le système toujours en production), après cela, vous fermez toutes les personnes connectées à la base de données (le temps d'arrêt commence ici), attendez que l'esclave se rattrape, promouvez-le (l'esclave) à maîtriser et redirige tous les clients / applications vers cette nouvelle version. Et tu as fini.
La documentation de Slony fournit une étape par étape pour mettre à niveau PostgreSQL à l'aide de Slony .
Lequel choisir
Eh bien, comme toujours cela dépend, en reprenant:
- Le dump + restore est le plus fiable, mais généralement le plus lent (le parallélisme peut cependant donner de très bons résultats)
- Le pg_upgrade est l'une des meilleures options pour les petits temps d'arrêt (si vous pouvez utiliser, voir les limitations), cela ne prend souvent que quelques minutes, même pour les grandes bases de données
- La réplication de déclenchement est sans aucun doute celle qui donne le moins de temps d'arrêt possible (près de zéro), mais elle est vraiment difficile à réaliser et je recommande uniquement aux personnes expérimentées (à la fois sur PostgreSQL et sur l'outil de réplication).
J'espère que je pourrais aider. Bonne chance.