🚀 go-pugleaf

On 2012-10-29, Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl> wrote:
> Mam dość sporą bazę danych :( a muszę w końcu podnieść wersję debiana.
> Zmiana pgsql 8.3->8.4 to niestety dla mnie przerwa na kilkanaście h
> backup+restore na co nie mogę sobie pozwolić. Jakie mam alternatywy?
> Czy robiąc upgrade do squeeze mogę 'zaholdować' pgsql w wersji 8.3? czy
> nie 'zaskoczy'? Może jakaś inna droga?

pg_upgrade ?

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

On 2012-10-29, hubert depesz lubaczewski <depesz@depesz.com> wrote:
> On 2012-10-29, Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl> wrote:
>> Mam dość sporą bazę danych :( a muszę w końcu podnieść wersję debiana.
>> Zmiana pgsql 8.3->8.4 to niestety dla mnie przerwa na kilkanaście h
>> backup+restore na co nie mogę sobie pozwolić. Jakie mam alternatywy?
>> Czy robiąc upgrade do squeeze mogę 'zaholdować' pgsql w wersji 8.3? czy
>> nie 'zaskoczy'? Może jakaś inna droga?
>
> pg_upgrade ?
>
> depesz

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.

-- 
Secunia non olet.
Stanislaw Klekot

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.

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

On 2012-10-29, hubert depesz lubaczewski <depesz@depesz.com> wrote:
> 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".

Możliwe. Znalazłem to w pakiecie Debiana.

> 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.

O to to. No popatrz, nie znałem. Zapiszę sobie. Jakich to fajnych rzeczy
można się dowiedzieć w internetsach ;)

-- 
Secunia non olet.
Stanislaw Klekot

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).

W artykule Sergiusz Rozanski napisał(a):

[...]

> 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).

A nie możesz tego "na chwilę"* wynieść do chroota?

pozdr,
fEnIo

* - prowizorki są dość trwałe stąd cudzysłów ;)

-- 
  ,''`.  Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
 : :' :       32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'           phone:+48602383548 | proud Debian maintainer and user
   `-            http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

Dnia 29.10.2012 Bartosz Feński aka fEnIo <fenio@debian.org> napisał/a:
> W artykule Sergiusz Rozanski napisał(a):
>
> [...]
>
>> 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).
>
> A nie możesz tego "na chwilę"* wynieść do chroota?
>
> pozdr,
> fEnIo
>
> * - prowizorki są dość trwałe stąd cudzysłów ;)

Spróbuję na razie zobaczyć ile potrwa restore na innej maszynie która jest w miarę
nie używana i od razu na 9.x - chyba to będzie najsensowniejszy test. I na własnej
kompilacji, nie na pakiecie, bo w 6 jest 8.4, to mi da zapas na kilka lat, chociaż
średni przyrost db 0.5GB/dobę mnie nie napawa optymizmem ku upgrade :)

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.

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

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.

Dnia 29.10.2012 Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl> napisał/a:
> 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.

Niestety dopiero rano zrobiłem postgisa w 9.2, więc zacząłem o 9:30 upload :/
nadal trwa, a ja jeszcze muszę zrobić w stopie backup! Nierealność.
Mam jednak 1 furtkę - największe jest archiwum, a to nie musi działać stale, raz
że mało kto tam zagląda, dwa może się ładować i 3 dni jak poinformuję klientów.
Więc zrobię 8.3->9.2 ale na 3 razy: struktura, dane bieżące - to jest moment,
postawienie usług i już na deser niech się ssają dane arch, mają swój tablespace,
swoje talerze, więc przeszkadzać za dużo nie będą.
Muszę to jednak trochę oskryptować (bo chyba nie ma backupu tabel z/bez _arch w
nazwie :) i potestować. Na razie pozwolę się temu backupowi rozpakować w 9.2 to
mi pozwoli też sprawdzić aplikacje z nową bazą - na szczęście izoluje apkę od
bazy nasze centralizowane api, więc poprawki to mały problem. Jak wywinduję pg,
to będę mógł się spokojnie zająć debianem.
Dzięki za podpowiedzi, które mnie jakoś naprowadziły na chyba słuszne rozwiązanie.
pg_upgrade w wolnej chwili też przetestuję jak robi z postgisem, bo to może się
na przyszłość przydać.

Użytkownik "Sergiusz Rozanski" <write-only-with-spf@media-lab.com.pl> 
napisał w wiadomości 
news:slrnk8vim9.fc8.write-only-with-spf@dns.media-lab.com.pl...
> Dnia 29.10.2012 Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl>
>>> 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.
> Niestety dopiero rano zrobiłem postgisa w 9.2, więc zacząłem o 9:30
> upload :/ nadal trwa, a ja jeszcze muszę zrobić w stopie backup!
> Nierealność. Mam jednak 1 furtkę - największe jest archiwum, a to nie
> musi działać stale, raz że mało kto tam zagląda, dwa może się ładować i
> 3 dni jak poinformuję klientów. Więc zrobię 8.3->9.2 ale na 3 razy:
> struktura, dane bieżące - to jest moment, postawienie usług i już na
> deser niech się ssają dane arch, mają swój tablespace, swoje talerze,
> więc przeszkadzać za dużo nie będą. Muszę to jednak trochę oskryptować
> (bo chyba nie ma backupu tabel z/bez _arch w nazwie :) i potestować. Na
> razie pozwolę się temu backupowi rozpakować w 9.2 to mi pozwoli też
> sprawdzić aplikacje z nową bazą - na szczęście izoluje apkę od bazy
> nasze centralizowane api, więc poprawki to mały problem. Jak wywinduję
> pg, to będę mógł się spokojnie zająć debianem. Dzięki za podpowiedzi,
> które mnie jakoś naprowadziły na chyba słuszne rozwiązanie. pg_upgrade w
> wolnej chwili też przetestuję jak robi z postgisem, bo to może się na
> przyszłość przydać.

A może spróbuj jeszcze na boku sprawdzić to z FlashCache? Wyniki na mysql 
były obiecujące 
http://www.mysqlperformanceblog.com/2010/05/18/flashcache-more-benchmarks/ , 
w pracy też sobie chwalimy. Do codziennej pracy nie polecałbym ale do 
odzyskania danych - czemu nie?

MaW