Re: WAL and pg_dump

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: WAL and pg_dump
Дата
Msg-id 1135354928.2964.617.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: WAL and pg_dump  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: WAL and pg_dump  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-admin
On Fri, 2005-12-23 at 08:43 -0500, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > Stephen Frost <sfrost@snowman.net> writes:
> > > As I recall, the initial backup of our 360GB (or so) database took
> > > about 6 hours and the restore only took about 2 hours.
> >
> > Really?  I'd certainly have guessed the opposite (mainly because of
> > index build time, constraint checking, etc during reload).  Could it
> > be that compression of the pg_dump output is swamping all else during
> > the backup phase?
>
> Sorry, I thought I was being clear (guess not)- I wasn't talking about
> using pg_dump but rather PITR and tar/untar.  I was trying to point out
> that using PITR and tar/untar can be much, much, much nicer when you
> have lots and lots of data to deal with (like a data warehouse would
> have...).

Yes, I don't think many people realise the performance you can get by
doing hot physical backup/restores.

I personally do not advocate any particular system architecture without
knowing the specific case. My work has been to provide the system
designer with more options should circumstances allow. Many systems
don't ever look sufficiently like just one of the classic design
patterns for us to use those designs directly, but we still need those
patterns to allow discussion.

> Of course, I can also do snapshots with the SAN, but that's a
> one-time thing unlike PITR where you can choose any point in time to
> recover to.

Why not use SAN Snapshots *and* PITR? They play nicely.

Best Regards, Simon Riggs



В списке pgsql-admin по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: WITH SYSID feature dropped
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: WAL and pg_dump