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
|
Список | 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 по дате отправления: