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.
 
Tout ça manque de précision:
  • Les DDL ne sont pas répliqués oui, après, de manière générale, on ne change pas le schéma tous les jours non plus. Il suffit de les appliquer sur l'instance répliqué. Le TRUNCATE n'est supporté qu'à partir de la version 11 donc dans votre cas oui ça peut poser problème.

ça pose problème dans ce cas précis avec les TRUNCATE TABLE.
 
  • La réplication des séquences, ça pose problème dans le cas où vous faite une bascule sur le secondaire en réplication logique. Il faut prévoir de les synchroniser lors de la bascule, il doit traîner des scripts qui font ça, c'est l'affaire de quelques minutes.
  • Les tables sans PK...comment dire... vous connaissez la normalisation...

Il y a certain cas où les PK ne sont pas nécessaire, sachant qu'une PK "coûte" un index et donc de la mémoire.

 
Ca dépend des installations :
  • Petite base avec downtime accepté, un simple dump/restore et au passage on recrée les index qui ne seront plus fragmentés.

Clairement on n'est pas dans ce cas là.
 
  • Grosses instances avec downtime réduit : pg_upgrade avec hardlink. Il faut suivre scrupuleusement la doc pour faire les opérations dans le bon ordre. Mais ça consiste grosso modo à une mise à jour du catalogue qui ne prendre que quelques minutes, sauf si vous avez un catalogue vraiment monstrueux.

pg_upgrade est très risqué avec les hardlinks.
 
  • Grosses instances avec downtime très réduit : slony ou réplication logique avec synchro des séquences.

pose les problèmes précédemment évoqués.
 
Il y a eu plusieurs articles sur le sujet ces dernières années, ça devrait vous aider.

Y'en a à la pèle, aucun dans des conditions réelles avec tout ce qu'on peut trouver comme cas.


--
Greg