Re: Issues Outstanding for Point In Time Recovery (PITR)
От | Zeugswetter Andreas SB SD |
---|---|
Тема | Re: Issues Outstanding for Point In Time Recovery (PITR) |
Дата | |
Msg-id | 46C15C39FEB2C44BA555E356FBCD6FA4961E10@m0114.s-mxs.net обсуждение исходный текст |
Ответ на | Issues Outstanding for Point In Time Recovery (PITR) ("J. R. Nield" <jrnield@usol.com>) |
Список | pgsql-hackers |
> Let me re-write it, and I'll post it in the next version. The section > dealt with what to do when you have a valid restored controlfile from a > backup system, which is in the DB_SHUTDOWNED state, and that points to a > valid shutdown/checkpoint record in the log; only the checkpoint record > happens not to be the last one in the log. This is a situation that > could never happen now, but would in PITR. But it would need to be restore's responsibility to set the flag to DB_IN_PRODUCTION, no? > Even if we shutdown before we copy the file, we don't want a file that > hasn't been written to in 5 weeks before it was backed up to require > five weeks of old log files to recover. So we need to track that > information somehow, because right now if we scanned the blocks in the > file looking for at the page LSN's, we greatest LSN we would see might > be much older than where it would be safe to recover from. That is the > biggest problem, I think. Well, if you skip a validity test it could be restore's responsibility to know which checkpoint was last before the file backup was taken. (When doing a backup you would need to include the last checkpoint info == pg_control at start of backup) Andreas
В списке pgsql-hackers по дате отправления: