Benutze hier an wenigen Stellen Postgres auf SL und wenig RHEL und bin damit sehr zufrieden, gerade die Konfiguration mag strikter, aber umso präziser sein als MySQL, die Dokumentation ist aber wirklich toll.
Frage an die erfahreneren Hasen hier: Postgres in RHEL6 und Klonen wird wohl bis zum "gehtnichtmehr" auf 8.4 bleiben - brauchen tu ich hier "Schnickschack" wie activeactive HA nicht, prinzipiell tut die aktuelle Version on EL6 eigentlich bestens.
Allerdings soll ab 9.x ein grösseres Update des DBMS einfacher sein, da die DB nicht exportiert und importiert werden muss. Gibt es andere Gründe auf die RPMs yum.postgresql.org zu wechseln, oder im Gegenteil. eher nicht?
Wer natürlich RHEL und Zertifizierungen und Support von RH für Postgres haben will, ist wohl gezwungen auf die von RH paketierte Version zurückzugreifen, aber zu der Kategorie gehöre ich eher nicht
Von Peter Eisentraut am Mo, 10. September 2012 um 23:41 #
Das was du meinst ist pg_upgrade und unterstützt Upgrades von 8.4 ab (8.3 mit Einschränkungen). Das hat aber nichts damit zu tun, welche RPMs man verwendet.
Das Umschalten zur nächsten Version erfolgt duch einen Link auf die entsprechende Version.
# cd /usr/local # ln -s postgres_9.0.9 postgres
Die yum - Pakete habe ich noch nicht getestet.
pg_upgrade habe ich mal testweise genutzt und keine Probleme festgestellt. Ich hatte mir jedoch nicht die Mühe gemacht, das bis zum letzten Bit zu testen - unsere Aplikation "funktionierte" auch mit der Version 9.1.5.
Wie gross ist denn deine DB ? Probiers doch mal aus, auf einem Testsystem, mit dem "sicherlich, natürlich" vorhandenen Backup - wenn's die Zeit erlaubt. Schlimmstenfalls geht's nicht. Die PG-Mailing-list ist sehr hilfsbereit.
Mit pg_dumpall kann man auch eine DB exportieren und mit psql wieder importieren - ist in der Doku beschrieben. Ggf. musst du den Dump mit einem awk/sed/xxx-Script massieren.
Von Matthias Müller am Di, 11. September 2012 um 09:59 #
Falls der Server mal abstürzt (was noch nie vorgekommen ist), könnte man debuggen. Performance-Probleme haben wir nicht, von daher hast du recht, ja, Gewohnheit.
Danke an alle für die Rückmeldungen, pg_upgrade war was ich suchte.
Da Postgres nicht gerade mein tägliches Brot ist, und ich recht glücklich mit den RPM's bin, verzichte ich allerdings im Moment lieber aufs selber bauen
Benutze hier an wenigen Stellen Postgres auf SL und wenig RHEL und bin damit sehr zufrieden, gerade die Konfiguration mag strikter, aber umso präziser sein als MySQL, die Dokumentation ist aber wirklich toll.
Frage an die erfahreneren Hasen hier: Postgres in RHEL6 und Klonen wird wohl bis zum "gehtnichtmehr" auf 8.4 bleiben - brauchen tu ich hier "Schnickschack" wie activeactive HA nicht, prinzipiell tut die aktuelle Version on EL6 eigentlich bestens.
Allerdings soll ab 9.x ein grösseres Update des DBMS einfacher sein, da die DB nicht exportiert und importiert werden muss. Gibt es andere Gründe auf die RPMs yum.postgresql.org zu wechseln, oder im Gegenteil. eher nicht?
Wer natürlich RHEL und Zertifizierungen und Support von RH für Postgres haben will, ist wohl gezwungen auf die von RH paketierte Version zurückzugreifen, aber zu der Kategorie gehöre ich eher nicht
Das was du meinst ist pg_upgrade und unterstützt Upgrades von 8.4 ab (8.3 mit Einschränkungen). Das hat aber nichts damit zu tun, welche RPMs man verwendet.
Wir machen hier die Installation der PG-Versionen aus dem Source Tarball. Das funktioniert bestens.
Wir brauchen lediglich die "Basic-Functions".
./configure --enable-debug --prefix=/usr/local/postgres_9.0.9
make
make install # als root
Das Umschalten zur nächsten Version erfolgt duch einen Link auf die entsprechende Version.
# cd /usr/local
# ln -s postgres_9.0.9 postgres
Die yum - Pakete habe ich noch nicht getestet.
pg_upgrade habe ich mal testweise genutzt und keine Probleme festgestellt. Ich hatte mir jedoch nicht die Mühe gemacht, das bis zum letzten Bit zu testen - unsere Aplikation "funktionierte" auch mit der Version 9.1.5.
Wie gross ist denn deine DB ? Probiers doch mal aus, auf einem Testsystem, mit dem "sicherlich, natürlich" vorhandenen Backup - wenn's die Zeit erlaubt. Schlimmstenfalls geht's nicht. Die PG-Mailing-list ist sehr hilfsbereit.
Mit pg_dumpall kann man auch eine DB exportieren und mit psql wieder importieren - ist in der Doku beschrieben.
Ggf. musst du den Dump mit einem awk/sed/xxx-Script massieren.
Viel Glück
Matthias
Debuggt ihr tatsächlich den DB Server im Livebetrieb, oder ist das eher aus Gewohnheit mit im configure?
Falls der Server mal abstürzt (was noch nie vorgekommen ist), könnte man debuggen. Performance-Probleme haben wir nicht, von daher hast du recht, ja, Gewohnheit.
Danke an alle für die Rückmeldungen, pg_upgrade war was ich suchte.
Da Postgres nicht gerade mein tägliches Brot ist, und ich recht glücklich mit den RPM's bin, verzichte ich allerdings im Moment lieber aufs selber bauen