🚀 go-pugleaf

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