Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

POSTGRESQL przywracanie bazy z dumpa - gdzieś się zaciąłem

641 views
Skip to first unread message

i/o

unread,
Mar 8, 2011, 3:08:55 PM3/8/11
to
Baza źródłowa 8.2
baza docelowa 8.4

archiwizacja wykonana komendą pg_dump -v -Z 9 > kopia.sql.gz


wydawało mi się że kiedyś przywrócenie bazy testowałem i robiłem tak że
plik gz wykompresowałem i dalej w psql przez parametr \i sciezka do pliku

ale dziś próbuję i jakoś mi nie idzie - w trakcie wykonywania SQL
wyrzuca jakiś błąd z gatunku nie rozpoznana funkcja... i zwyczajnie się
wywala

I poległem

Nie czuję się specem linuxowym - jakimś błyskotliwym strasznie - wiem
ile muszę i tyle na ile czasu mi starcza

To przywracanie to jest test przed migracją bazy na nowy serwer -
testuję to na innej maszynce(testowej) jednak z docelowym linuxem i
docelowym postgresem. (Ubuntu 64bit)
mam jednak inny dysk i mniej ramu (1GB) tymczasem plik po dekompresji z
gz ma około 30GB

Podpowiedzcie czy ja coś robię nie tak...może to archiwum jest źle tworzone

pg_restore nie chce zadziałać na plik skompresowany, na wykompresowany
również nie chce - twierdząc że format jest nierozpoznany - not valid

może ktoś poradzi jak powinno się wykonać archiwum i później odtworzenie

please please


żeby była jasność - windowsowymi narzędziami tego nie robię.... bo jakoś
stawiały opór przy przywracaniu triggerów, też w sumie nie wiem czemu -
moze przez to że używam pgadmina 1.6.3 - jedynego słusznego ba ma helpa
w sobie a nie na www

Paweł Matejski

unread,
Mar 8, 2011, 3:28:06 PM3/8/11
to
W dniu 08.03.2011 21:08, i/o pisze:

> Baza źródłowa 8.2
> baza docelowa 8.4
>
> archiwizacja wykonana komendą pg_dump -v -Z 9 > kopia.sql.gz
>
>
> wydawało mi się że kiedyś przywrócenie bazy testowałem i robiłem tak że
> plik gz wykompresowałem i dalej w psql przez parametr \i sciezka do pliku
>
> ale dziś próbuję i jakoś mi nie idzie - w trakcie wykonywania SQL
> wyrzuca jakiś błąd z gatunku nie rozpoznana funkcja... i zwyczajnie się
> wywala
>
> I poległem
>
> Nie czuję się specem linuxowym - jakimś błyskotliwym strasznie - wiem
> ile muszę i tyle na ile czasu mi starcza

Podstawowa wiedza to ta, że jeśli Ci błąd nic nie mówi, nie znaczy, że komuś innemu nie powie.
Więc JAKI TO BŁĄD!!

> To przywracanie to jest test przed migracją bazy na nowy serwer -
> testuję to na innej maszynce(testowej) jednak z docelowym linuxem i
> docelowym postgresem. (Ubuntu 64bit)
> mam jednak inny dysk i mniej ramu (1GB) tymczasem plik po dekompresji z
> gz ma około 30GB
>
> Podpowiedzcie czy ja coś robię nie tak...może to archiwum jest źle tworzone
>
> pg_restore nie chce zadziałać na plik skompresowany, na wykompresowany
> również nie chce - twierdząc że format jest nierozpoznany - not valid
>
> może ktoś poradzi jak powinno się wykonać archiwum i później odtworzenie

Tak.
pg_dump -F c

i potem w takim dumpie masz wszystko niezbędne (poza użytkownikami). I przy pomocy pg_restore może impotować
bezpośrednio do bazy, albo wygenerować plik SQL, który ewentualnie możesz przeedytować.

--
P.M.

i/o

unread,
Mar 8, 2011, 3:58:58 PM3/8/11
to
Między Bogiem a prawdą przeszło mi to przez myśl, jednak nie miałem dość
miejsca na taki trik...i nie byłem już pewien czy to zda egzamin

ten błąd to jakiś śmieć w SQL po dekompresji tak sądzę.....gdzieś coś
się pokopało, zgubiło znak lub cokolwiek i już potem sypało błędem

nic konktretnego - tak jakby chciało wykonać SQL ale nie trafiło na
komendę tylko na jakieś inne rzeczy

nie warto się rozwodzić - rozumiem komendę jaką mi napisałeś - z userami
nie powinno być problemu

ta komenda oznacza - rób dumpa w formacie catalog

już testuję jak podmapować sobie jakiś zasób w miarę nieograniczony żeby
ten dump miał się gdzie wykonać

w zasadzie będę tego dumpa rzucać przez sieć wprost do maszyny, gdzie
potem będę realizować przywracanie - sieć mam Gigabirową więc powinna
nadążyć

NIEDZIELA CZAS TESTÓW :))


Dziękuję za podpórkę

i/o

unread,
Mar 8, 2011, 4:00:44 PM3/8/11
to
Oczywiście miało być Gigabitową ;)

W dniu 2011-03-08 21:58, i/o pisze:

Paweł Matejski

unread,
Mar 8, 2011, 4:28:16 PM3/8/11
to
W dniu 08.03.2011 21:58, i/o pisze:

> Między Bogiem a prawdą przeszło mi to przez myśl, jednak nie miałem dość
> miejsca na taki trik...i nie byłem już pewien czy to zda egzamin
>
> ten błąd to jakiś śmieć w SQL po dekompresji tak sądzę.....gdzieś coś
> się pokopało, zgubiło znak lub cokolwiek i już potem sypało błędem
>
> nic konktretnego - tak jakby chciało wykonać SQL ale nie trafiło na
> komendę tylko na jakieś inne rzeczy
>
> nie warto się rozwodzić - rozumiem komendę jaką mi napisałeś - z userami
> nie powinno być problemu
>
> ta komenda oznacza - rób dumpa w formacie catalog
>
> już testuję jak podmapować sobie jakiś zasób w miarę nieograniczony żeby
> ten dump miał się gdzie wykonać
>
> w zasadzie będę tego dumpa rzucać przez sieć wprost do maszyny, gdzie
> potem będę realizować przywracanie - sieć mam Gigabirową więc powinna
> nadążyć
>
> NIEDZIELA CZAS TESTÓW :))

To do testów zapoznaj się z opcją -s, zaoszczędzisz na czasie kopiowania dumpów.
Jak już schemat zaimportujesz, to z danymi nie powinno być kłopotów (poza czasem ich importu).

A na czas importu danych możesz zmienić w configu postgres

fsync = on

na

fsync = off

Tylko po wszystkim nie zapomnij zmienić z powrotem, bo możesz się nieprzyjemnie zdziwić, jak Ci braknie prądu, albo
serwer z innych powodów odmówi zapisów na dysk. ;)

--
P.M.

i/o

unread,
Mar 12, 2011, 8:35:31 AM3/12/11
to
Testy wypadły bardzo pozytywnie ;))

wielkość dumpa nie ma już znaczenia - tzn na serwerze nie mam tyle
miejsca ale szybka sieć i montowanie przez Sambę pomogły mi w sprawnym
wykonaniu testu

Przy okazji wyszło parę spraw z kodowaniami ale to już był drobiazg

Dziękuję wszystkim dobrym duszyczkom, które mi pomogły a szczególnie
Panu Pawłowi Matejskiemu


ciach---------------

0 new messages