PostgreSQL upgrade

[Verwijderd]

Wat ik me nou afvraag he, wat is de makkelijkste manier om PostgreSQL te upgraden....

In de manual staat een stukje over upgraden:

2. To back up your database installation, type:
pg_dumpall > outputfile
[...]
"pg_dumpall" does not save large objects. Check the documentation if you
need to do this.

Hoe moet ik nou weten of een klant gebruik maakt van large objects? Dan kan ik zeker 10GB databases door gaan zitten spitten om te kijken of er large objects in zitten. En er zijn nog een paar redenen waardoor export import niet direct 100% smooth loopt. Dus wat ik me nu best wel afvraag:

is er geen makkerlijker manier om je database files te upgraden? Is er niet een progje misschien wat gewoon de bestanden kan omzetten zonder export import?

Ik heb nu trouwens 7.2.x en wil naar 7.4.

TIA

[usr-local-dick]

is er geen makkerlijker manier om je database files te upgraden? Is er niet een progje misschien wat gewoon de bestanden kan omzetten zonder export import?

Ik heb nu trouwens 7.2.x en wil naar 7.4.

Ik ben precies met hetzelfde bezig nu, mijn webman is bezig een app te maken met postgresql, en ik heb voor het gemak de stable versie van Debian geinstalleerd.
Maar bij nader inzien is die versie (7.2.1 dacht ik) niet goed.
Wij maken ook gebruik van LO's en dan werkt de backup niet (goed).
Ik vind dit echt een major issue, wat heb je nu aan een database als je geen backups kan maken Heb allerlei manieren gevonden, maar onze dumps gaan niet eens in dezelfde versie van PQ goed terug, laat staan in een andere versie
Let op dit is dit voor EEN database. Dan hebben we het nog niet over een dump van *alle* databases. Daar zijn dan een paar gehackte scriptjes voor nodig zoals:

http://www.infofind.com/postgreSQL/

Maarja als 1 db al niet werkt dan gaat meerdere zeker niet lukken...

Het is gewoon een mad bug zo te zien:
http://groups.google.nl/g...%26btnG%3DGoogle%2Bzoeken

Anyway aangezien we gelukkig nog in het ontwikkel stadium zijn van onze app, ben ik op dit moment een deb aan het maken voor POstgresql-7.4 voor woody. Als die goed draait check ik of die wel goed backups kan maken met dump/restore en dan gaan we live met 7.4

Alles wat ik vindt met google over postgres en backup/restore/upgrade in combinatie met LO's stemt mij diep ongelukkig

Hij mag wel veel meer features hebben dan MySQL, maar daar zit tenminste een goede mogelijkheid voor het (eenvoudig) maken van full dumps.
Die dus ook weer te gebruiken zijn naderhand, dat is heel fijn.

[ACM]

usr-local-dick schreef op 04 december 2003 @ 18:01:
Hij mag wel veel meer features hebben dan MySQL, maar daar zit tenminste een goede mogelijkheid voor het (eenvoudig) maken van full dumps.
Die dus ook weer te gebruiken zijn naderhand, dat is heel fijn.

De dump-tool van postgresql is "technisch" beter dan die van mysql, mysql kent geen goede hotbackup mogelijkheid, als er wat wijzigt in de database tijdens het maken van de dump is het maar afwachten of het meegenomen is of niet.

Als het toevallig een foreign-key relatie betrof ben je potentieel flink de sjaak.

Als je zeker wilt weten dat het goed gaat kan je denk ik het beste zoiets doen (let op, dit is pseudocode):
$databases = psql -l -U postgres # list alle databases
pg_dumpall -g > globals.sql # creation data voor o.a. users
foreach($databases as $database)
pg_dump -b -Fc -Z9 $database -U postgres > $database-$datum.dump # dump de database in het custom formaat met een compressie-level van 9

't Voordeel is dat je dan ook per gebruiker kunt dumpen en het is redelijk simpel te scripten.

Restoren van de data gaat ongeveer zo:
psql -U postgres template1 < globals.sql
foreach($databases as $database)
pg_restore -Fc -i -C < $database-$datum.dump # hercreeer de database, en zorg dat ie zich niet zoveel aantrekt van het versie-verschil

[usr-local-dick]

ACM schreef op 04 december 2003 @ 18:36:
[...]

De dump-tool van postgresql is "technisch" beter dan die van mysql, mysql kent geen goede hotbackup mogelijkheid, als er wat wijzigt in de database tijdens het maken van de dump is het maar afwachten of het meegenomen is of niet.

Als het toevallig een foreign-key relatie betrof ben je potentieel flink de sjaak.

Als je zeker wilt weten dat het goed gaat kan je denk ik het beste zoiets doen (let op, dit is pseudocode):
$databases = psql -l -U postgres # list alle databases
pg_dumpall -g > globals.sql # creation data voor o.a. users
foreach($databases as $database)
pg_dump -b -Fc -Z9 $database -U postgres > $database-$datum.dump # dump de database in het custom formaat met een compressie-level van 9

't Voordeel is dat je dan ook per gebruiker kunt dumpen en het is redelijk simpel te scripten.

Restoren van de data gaat ongeveer zo:
psql -U postgres template1 < globals.sql
foreach($databases as $database)
pg_restore -Fc -i -C < $database-$datum.dump # hercreeer de database, en zorg dat ie zich niet zoveel aantrekt van het versie-verschil

Dit lijkt heel erg veel op het script wat in de link in mijn eerdere post staat.
Het probleem hier is dat bepaalde databases ook met de pg_dump/pg_restore utilities niet goed gebackupped kunnen worden.
Ik zag in de changelog van 7.4 dat juist in die tools major improvements zaten, vandaar dat ik met 7.4 aan de slag wil...

[ACM]

usr-local-dick schreef op 04 december 2003 @ 18:42:
Dit lijkt heel erg veel op het script wat in de link in mijn eerdere post staat.
Het probleem hier is dat bepaalde databases ook met de pg_dump/pg_restore utilities niet goed gebackupped kunnen worden.
Ik zag in de changelog van 7.4 dat juist in die tools major improvements zaten, vandaar dat ik met 7.4 aan de slag wil...

Niet? Wat kan je niet goed dumpen met pg_dump en restoren met pg_restore dan?
Waar denk je dat de -b parameter voor was die ik hierboven gaf? Die is voor de blobs waar in de topicstart over geklaagd wordt. pg_dumpall is idd net iets te beperkt voor dat soort zaken.
Maar een beetje werkbare mysql-backup-setup is ook niet gebaseerd op mysql_dump -aA ...

De improvements voor die tools zijn trouwens voornamelijk in de richting van rewrites in C, met de potentie er later meer mee te kunnen ik weet niet of de verandering in de tools een drijfveer zou moeten zijn om pg7.4 ipv pg7.2 toe te passen.
De vele andere verbeteringen (o.a. de enorm verbeterde performance, snellere connects, etc etc) zijn imho betere redenen ervoor

Btw, ik moet er wel bij vermelden dat ik eigenlijk nooit de lo's van postgres gebruikt heb, simpelweg omdat ik ze ofwel niet nodig had of bytea handiger vond op dat moment.

[ Voor 7% gewijzigd door ACM op 04-12-2003 19:25 ]

[Verwijderd]

goed... heb inmiddels al een productiedatabase gemold (drop database in de verkeerde xterm; leve de backup) en zo... maar ik geloof dat ik hier echt wat aan heb

thanx