/usr/ports/UPDATING entry 20190929 - PostgreSQL

xcvb

Well-Known Member
Es geht um die Upgrade-Beschreibung zu PostgreSQL in /usr/ports/UPDATING. Dort wird folgendes Prozedere empfohlen:

# service postgresql stop
# pkg create postgresql95-server postgresql95-contrib
# mkdir /tmp/pg-upgrade
# tar xf postgresql95-server-9.5.19.txz -C /tmp/pg-upgrade
# tar xf postgresql95-contrib-9.5.19.txz -C /tmp/pg-upgrade
# pkg delete -f databases/postgresql95-server databases/postgresql95-contrib databases/postgresql95-client

Now update PostgreSQL:

pkg user:
# pkg install databases/postgresql11-server databases/postgresql11-contrib
# pkg upgrade

Portmaster users:
# portmaster databases/postgresql11-server databases/postgresql11-contrib
# portmaster -a

Portupgrade users:
# portinstall databases/postgresql11-server databases/postgresql11-contrib
# portupgrade -a

After installing the new PostgreSQL version you need to convert
all your databases to new version:

# su -l postgres -c "/usr/local/bin/initdb --encoding=utf-8 --lc-collate=C -D /var/db/postgres/data11 -U pgsql"
# chown -R postgres /usr/local/pgsql/data/
# su -l postgres -c "pg_upgrade -b /tmp/pg-upgrade/usr/local/bin/ -d /usr/local/pgsql/data/ -B /usr/local/bin/ -D /var/db/postgres/data11/ -U pgsql "

Now the migration is finished. You can start PostgreSQL again with:

# service postgresql start

Auf meinem Testserver hab ich das neulich mal so durchgespielt. Ergebnis: Bei pg_upgrade läuft die Sache auf den Hammer. Die exakte Fehlermeldung weiß ich nicht mehr, aber es lief darauf hinaus, dass die alte Postgres-Installation irgendwelche shared objects von devel/icu nicht gefunden hat.

devel/icu wurde auch bei dem empfohlenen pkg upgrade (bzw. portmaster/portupgrade -a) aktualisiert. Nicht verwunderlich, dass die alte Installation dann nicht mehr funktioniert, oder?

Sollte ich tz@ mal kontaktieren, dass ggf. der Eintrag in UPDATING angepasst wird?
 
Ja, das scheint eine ungeschickte Upgrade-Strategie zu sein. Einen solchen Major-Upgrade würde ich eh lieber als isolierte Aktion machen.
Aber hier geht es um eine andere Zielgruppe: um diejenigen, die die Datenbank lediglich als Hilfssystem installiert haben, ohne sie besonders zu administrieren. (Ob das bei einer derart mächtigen RDBMS wirklich praktikabel ist, sei mal dahingestellt.)

Welchen Grund könnte es haben, dass da mittendrin auch alle anderen Ports upgraded werden? Für irgendwas muss das ja gut sein.

Und, zumindest mit Portupgrade sollte der Fehler nicht passieren - da werden die alten Libraries nach lib/compat/pkg gelegt.
 
Ich mache vor dem Upgrade noch ein pg_dumpall. Dann deinstalliere ich alles und installiere die neue Version. Ich passe dann die Config-Dateien an und mache einen pg_restore.

Ich habe mir überlegt zu warten, bis Ende des Jahres die 12er Version zur Produktion freigegeben wird.
 
Mal so als Tipp: PostgreSQL aus den Paketen zu nutzen ist - unabhängig des Betriebssystems - eine völlig legitime und sinnvolle Sache, wenn man einfach nur eine Datenbank braucht. Wenn man aber größere Cluster betreibt, mit etlichen Gigabyte Daten, womöglich mit Replikation, WAL-Archiven und allem Schnick-Schnack, will man das eher nicht. Denn da kommt es meist auf genaue Versionsstände drauf an, Updates wollen sauber vorbereitet und durchgeführt sein, man will dafür auf ältere Server-Binaries zurückgreifen können, etc. Das Paketmanagement macht da nur mehr Arbeit und Ärger, als es abnimmt.

Wir haben dafür grob so eine Verzeichnisstruktur:
Code:
/data
/data/bin/10.10
/data/bin/11.5
/data/bin/12.0
/data/bin/active
/data/cluster/10
/data/cluster/11
/data/cluster/12

/data/bin/$VERSION sind selbst gebaute PosgreSQL-Installationen der jeweiligen Version. Also ./configure --prefix=/data/bin/10.10 als Beispiel. PostgreSQL hat so gut wie keine Abhängigkeiten und lässt sich wirklich kinderleicht selbst bauen. /data/bin/active ist ein Symlink auf die jeweils aktiv laufende Version, die rc-Scripte nutzen es und /data/bin/active/bin liegt im $PATH. /data/cluster/$HAUPTVERSION sind die jeweiligen Datenverzeichnisse ode rin PostgreSQL-Sprech Cluster, für jede Version, die dort ein Uprade braucht, eines. Natürlich muss man die nicht in alle Ewigkeiten aufbewahren, wir löschen nach erfolgreichem Upgrade die dann nicht mehr benötigte Version.

Ein Update ohne Cluster-Upgrade wird dann so eingespielt:
  • Release Notes lesen. Das ist wirklich wichtig, da dort mögliche Fallstricke drinstehen.
  • Neue Version herunterladen, bauen und installieren.
  • Anwendungen anhalten.
  • Den Cluster herunterfahren.
  • /data/bin/active löschen und auf die neue Version gesetzt neu erstellen.
  • Den Cluster wieder starten.
  • Testen.
  • Anwendungen wieder starten.
Wenn es schief geht, setzt man /data/bin/active zurück und ist wieder auf der alten Version. Mit ein wenig Übung kann man die Downtime minimal halten, herunterfahren, Symlink umsetzen und wieder starten ist in unter 30 Sekunden zu machen.


Ein Update mit Cluster-Upgrade hat dann ein paar Schritte mehr:
  • Release Notes lesen. Das ist wirklich wichtig, da dort mögliche Fallstricke drinstehen.
  • Die Configs auf notwendige Anpassungen prüfen, die angepassten Versionen irgendwo ablegen.
  • Neue Version herunterladen, bauen und installieren.
  • Anwendungen anhalten.
  • Den Cluster herunterfahren.
  • /data/bin/active löschen und auf die neue Version gesetzt neu erstellen.
  • initdb zum Erstellen des neuen Clusters ausführen.
  • Die angepassten Configs in den neuen Cluster kopieren.
  • pg_upgrade ausführen und eine große Tasse Kaffee holen.
  • Den Cluster wieder starten.
  • Testen.
  • Anwendungen wieder starten.
Da man beide PostgreSQL-Versionen verfügbar hat, ist es wesentlich einfacher, als da mit dem Paketmanagement rumzuhampeln. Und auch hier kann man im Problemfall einfach den alten Symlink zurücksetzen und den alten Cluster wieder starten.
 
Zurück
Oben