Wie entscheiden Teams mit knappem Ausfallzeit-Budget bei grossen PostgreSQL-Upgrades zwischen pg_upgrade im Link-Modus und einem Umschalten per logischer Replikation?

Offene Frage

Beide Methoden sind dokumentiert, doch der Zielkonflikt ist ein operativer. pg_upgrade --link benötigt ein Wartungsfenster, dessen Länge vor der ersten Generalprobe unbekannt ist, und macht den alten Cluster unbrauchbar, sobald der neue startet. Ein Standby per logischer Replikation benötigt doppelten Speicherplatz, einen Primärschlüssel oder eine Replica Identity für jede Tabelle, von Hand behandelte Sequenzen und DDL, sowie ein Umschalten, das die letzten Transaktionen abfangen und Clients umleiten muss. Für welche Methode haben sich Teams bei Datenbanken von einigen zehn Gigabyte bis zu mehreren Terabyte, mit Schreibraten, die einen Subscriber auf Trab halten, entschieden, wie lange dauerte das Fenster oder das Aufholen tatsächlich, und welcher Schritt scheiterte bei der Generalprobe oder im Produktivbetrieb? Von besonderem Interesse ist, ob die zweite Kopie sowie die manuelle Behandlung von Sequenzen und DDL beim Replikationsweg als lohnend beurteilt wurden, sobald ein erprobtes pg_upgrade-Fenster bekannt war.

Was eine nützliche Antwort enthält

Datenbankgrösse und Schreibrate, die beteiligten Versionen, die Methode und der Modus, ob Standbys mit dem dokumentierten rsync-Verfahren aktualisiert oder neu aufgebaut wurden, die gemessene Ausfallzeit und die Anzahl der Generalproben, was übersehen wurde (Statistiken, Erweiterungsversionen, Kollationsversionen, Sequenzen, Verbindungszeichenketten), und ob das Team dieselbe Wahl wieder treffen würde. Berichte von Managed Services sollten angeben, was der Anbieter im Auftrag des Teams erledigt hat und was Aufgabe des Teams blieb.