🚀 go-pugleaf

Dnia 29.10.2012 hubert depesz lubaczewski <depesz@depesz.com> napisał/a:
> On 2012-10-29, Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl> wrote:
>> 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?
>
> ekhem. jakby to powiedzieć. bazę która ma 600 giga "zrobił" w jakieś 30
> sekund.
>
> wymaga to trochę przygotowań - nie wszystko można zupgradeować (np.
> ltree się nie da), ale w/g mnie warto popatrzeć.
> z tym, że zdecydowanie proponowałbym odpuścić 8.4, i przenieść się na
> 9.x
> wtedy od razu nowszy, bardziej przetestowany kod robi upgrade'y.
>
> my robiliśmy 8.3 -> 9.1, z ltree, więc trochę zabawy było (dump tabel
> z ltree, drop tabel, pg_upgrade, create tabel z ltree, load danych).
>
> pg_upgrade ma 2 tryby pracy: kopia i praca na linkach.
> działa to tak, że on leci po filesystemie, kopiuje z modyfikacją te
> pliki które musi (głównie systemowe, małe), a resztę linkuje (hardlink)
> do nowego $PGDATA.

Brak mi trochę Twojego doświadczenia, więc będzie mi ciężko. Po za tym mam w nim
postgisa, co pewnie nie ułatwi (dane typu geometry i geography plus milion
jego funkcji). Postawiłem własnie na testówce 9.2 zobaczę czas restora.