Le mar. 11 juin 2019 à 11:41, Greg greg-frsag@duchatelet.net a écrit :
Le mar. 11 juin 2019 à 11:25, adrien nayrat adrien.nayrat.axess@gmail.com a écrit :
A/ on met à jour le master PG de façon classique, tous les slaves sont
pétés et il faut ensuite les reconfigurer. Problèmes: le temps de l'upgrade toute la charge se retrouve sur le master seul, et le temps de coupure correspond au pg_upgrade, soit plusieurs heures pour un serveur d'1To, et il faut disposer du double de l'espace disque (soit 2To mini) sur ce master, ce qui n'est plus le cas.
Non, vous pouvez faire un upgrade avec des hardlink. L'upgrade est bien plus rapide (mais pas de rollback possible sur l'ancienne instance une fois que la nouvelle instance a été démarrée). (J'ai un peu l'impression que c'est ce que fait MySQL : https://dev.mysql.com/doc/refman/8.0/en/upgrading-what-is-upgraded.html)
Certes, mais je ne me risquerai pas à mettre à jour un serveur sans rollback RAPIDE possible.
Simple question par pure curiosité, dans le premier mail tu disais que les upgrade MySQL se faisait plutôt facilement en décrivant le process. Est-ce qu'il est possilbe de faire un rollback après avoir démarré MySQL?
Si la réponse est non, ça correspond grosso modo au pg_upgrade + hardlink. La seule différence que je vois est que MySQL supporte la réplication entre versions majeures différente, là où la réplication pg est plus bas niveau et ne permet pas ce genre de réplication.