Re: PITR Functional Design v2 for 7.5

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re: PITR Functional Design v2 for 7.5
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA40184D016@m0114.s-mxs.net
обсуждение исходный текст
Ответ на PITR Functional Design v2 for 7.5  ("Simon Riggs" <simon@2ndquadrant.com>)
Ответы Re: PITR Functional Design v2 for 7.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > To clarify:
> > I'd expect a cluster to be workable, if I
> > - disable VACUUM until backup completed
> > - issue CHECKPOINT
> > - backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
> > - backup all datafiles (which include at least all completed transaction
> > data at checkpoint time)
> > and then
> > - restore datafiles and clog
> > - bring up pgsql.
>
> Why is that a useful approach?  You might as well shut down the
> postmaster and do a cold filesystem backup, because you are depending on
> the data files (including clog) not to change after the checkpoint.  You
> cannot make such an assumption in a running database.

I think there is a misunderstanding here.

What I think is possible is the following (continuous backup of WAL assumed):
- disable VACUUM
- issue CHECKPOINT "C1"
- backup all files
- reenable VACUUM

- restore files
- adapt pg_control (checkpoint "C1")
- recover WAL until at least end of backup

The db is inconsistent until you recovered all WAL (PITR) that accumulated during
file backup.

I am not sure about clog, isn't clog logged in xlog ?

Andreas


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

Предыдущее
От: Kurt Roeckx
Дата:
Сообщение: Re: Timing of 'SELECT 1'
Следующее
От: "Marcelo Carvalho Fernandes"
Дата:
Сообщение: PANIC on start