Vous n'êtes pas identifié(e).
Pages : 1
Bonjour.
je dois migrer des instances 9.1.6 vers du 9.5. Au passage je change de serveurs et de distribution Linux : de RedHat RHEL 5 vers Debian. Chaque serveur 9.1 aura un vis à vis en 9.5 (accès en ssh, et peut-être le port 5432 sera ouvert). J'aimerai autant que faire se peut avoir le minimum d'interruption de service.Chaque instance 9.1 a une unique base (en plus des template et de la base postgres). Volumetrie : la + grosse base fait 716 Go
1er scenario:
Il consiste à dumper la base de la 9.1 , puis à pousser le dump par scp sur l'instance 9.5 et à restaurer.
1ere question : est ce que c'est possible, j'ai quand même 4 versions d'écart ?
2eme question : la doc indique "il est recommandé d'utiliser le pg_dump de la version la + elevée". Dans mon cas il faudrait que j'utilise le pg_dump de la version 9.5. Ce qui ne m'arrange pas : je ne suis pas sûr de pouvoir installer les binaires 9.5 sur mon serveur 9.1. Je voudrai éviter de faire le dump à travers le réseau (en utilisant pg_dump de la 9.5 vers le host de la 9.1). Puis-je faire le dump avec pg_dump de la 9.1 et restaurer ce dump avec le pg_restore de la 9.5 ?
Je pense que ce scenario est peut-être le pire concernant l'interruption de service, mais c'est peut-être le plus secure pour les données.
2eme scénario : pg_upgrade
Même remarque que pour la question 1 : 4 version d'écart, ca fait beaucoup. Question subsidiaire : autant j'ai "confiance" en pg_dump+pg_restore que j'utilise beaucoup , autant je suis plus inquiet sur pg_upgrade que je n'ai jamais utilisé. Ce sera certainement beaucoup plus rapide que pg_restore, mais je vais consommer le double d'espace disque, et il faudra bien qu'à un moment je pousse le répertoire data par scp (ou rsync) et vu les volumes ce sera peut-être pire qu'un dump+restore
Voyez-vous un autre scénario , à base de réplication par exemple. L'idée serait de répliquer mon instance 9.1 sur une 9.1 debian (si je peux installer une 9.1 sur debian à côté de la 9.5, je pense que oui) pour en faire un warm standby, puis d'arrêter le maitre et d'utiliser pg_upgrade sur debian. C'est peut-être comme cela que je minimiserai l'interruption de service : j'économise le temps à faire le dump, le temps de pousser le dump par scp.
Cordialement
Hors ligne
1ere question : est ce que c'est possible, j'ai quand même 4 versions d'écart ?
Oui, c'est tout à fait possible.
2eme question : la doc indique "il est recommandé d'utiliser le pg_dump de la version la + elevée". Dans mon cas il faudrait que j'utilise le pg_dump de la version 9.5. Ce qui ne m'arrange pas : je ne suis pas sûr de pouvoir installer les binaires 9.5 sur mon serveur 9.1. Je voudrai éviter de faire le dump à travers le réseau (en utilisant pg_dump de la 9.5 vers le host de la 9.1). Puis-je faire le dump avec pg_dump de la 9.1 et restaurer ce dump avec le pg_restore de la 9.5 ?
Possible mais pas garantie. Par contre, vous pouvez à coup sûr installer les RPM de la 9.5 sur le serveur qui a déjà une version 9.1. Donc autant le faire proprement.
Je pense que ce scenario est peut-être le pire concernant l'interruption de service, mais c'est peut-être le plus secure pour les données.
Entièrement d'accord.
2eme scénario : pg_upgrade
La réplication entre deux OS différent n'est pas forcément une bonne idée. La glibc ne sera pas forcément identique, ce qui peut poser des problèmes au niveau des index.
Personnellement, entre le chemin d'OS et le changement de version, je passerais plutôt par la bonne vieille méthode du pg_dump. Je passerais par le pg_restore parallélisé pour améliorer les performances de la restauration.
Guillaume.
Hors ligne
Bonjour et merci pour cette réponse rapide. Cela me conforte dans mon idée de passer par dump/restore. Bonne journée.
Hors ligne
Pages : 1
