🚀 go-pugleaf

Dnia 29.10.2012 hubert depesz lubaczewski <depesz@depesz.com> napisał/a:
> On 2012-10-29, Stachu 'Dozzie' K. <dozzie@go.eat.some.screws.spammer.invalid> wrote:
>>> pg_upgrade ?
>> Prędzej pg_upgradecluster (pg_upgrade to wynalazek z 9.x, jeśli dobrze
>> pamiętam). Ale i tak Sergiusz by musiał sprawdzić, ile mu to czasu
>> zajmie.
>
> nie wiem co to pg_upgradecluster - nazwa brzmi strasznie "debianowsko".
>
> pg_upgrade to włączony w źródła "pg_migrator", który obsługuje 8.4.
> http://pgfoundry.org/projects/pg-migrator/
> plusem jest to, że działa to bardzo szybko.

Pytanie jak szybko :( to leci po strukturach czy jednak tyka wszystkiego.
Bo jak wszystkiego to i tak mam przechlapane. Ponad 0.5TB bazy, główny
tablespace ma 40GB, 500GB na tablespace w /archiwum. To generalnie musi chodzić
nonstop, godzinkę, może 2 wyrwę w weekend. Stoi to na 4 blackach 0+1.
Archiwum w miarę zdefragmentowane, ale aktualne pliki to jest seek na seeku.
BTW to zrobi w miejscu czy przepisze? Bo jak przepisze to potrzebuję jeszcze
dodatkowej przestrzeni?
Dla ułatwienia dump_all się robi 4h, raz na tydzień, reszta leci walbackupem i
conocnym rsync na 2 drugie dyski też koło 4h baza jest w stanie backupu, więc
jakby co zachowam dump i przestrzeń mam, ale gorzej z zatrzymaniem systemu i
później to jeszcze przegrać na własciwe miejsce.
500GB to 500000MB, nawet przy idelnych warunkach na liniowy odczyt około 200MB/s
(na co nie mogę liczyć) to jest 2500sekund 41minut - ale jak rsync trwa 4 to
migrator szybciej nie skoczy chyba.

Osobiście wolałbym to zrobić na 2 baty - podnieść debiana zachowując 8.3, a
później windować bazę (może już do 9 aby nie kombinować 100 razy).