Von blablabla am Mo, 10. September 2012 um 16:32 #
Was die Postgres-Entwickler leisten ist ungeheure Professionalität und ein Stück Software das in der realen Welt einfach sein dienst verrichtet, zuverlässig stabil und sicher, genauso sollte Enterprisesoftware sein. Vielenvielen Dank für ein solch gutes Stück Software (mit weitem abstand meine lieblings R-DB)
Was die Postgres-Entwickler leisten ist ungeheure Professionalität und ein Stück Software das in der realen Welt einfach sein dienst verrichtet, zuverlässig stabil und sicher
Exakt. Dagegen kann man mySQL inne Tonne kloppen. Aber ich will jetzt hier kein Flamewar lostreten.
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
Was die Postgres-Entwickler leisten ist ungeheure Professionalität und ein Stück Software das in der realen Welt einfach sein dienst verrichtet, zuverlässig stabil und sicher, genauso sollte Enterprisesoftware sein.
Vielenvielen Dank für ein solch gutes Stück Software (mit weitem abstand meine lieblings R-DB)
Soll das heißen all die Jahre gingen keine "Covered Indexe"?
Was die Postgres-Entwickler leisten ist ungeheure Professionalität und ein Stück Software das in der realen Welt einfach sein dienst verrichtet, zuverlässig stabil und sicher
Exakt.
Dagegen kann man mySQL inne Tonne kloppen.
Aber ich will jetzt hier kein Flamewar lostreten.
Gruß
MichaelK
Aber ich: Wie so oft in der IT setzt sich das schlechtere durch.
Es hat sich doch beides durchgesetzt.
Langeweiler.
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