Re: Recovery target 'immediate'
От | Magnus Hagander |
---|---|
Тема | Re: Recovery target 'immediate' |
Дата | |
Msg-id | CABUevEyZLo1oekAtZucqZNQMv5+Cj7nWB0zk_n+bWRAYbiGC0Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Recovery target 'immediate' (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Recovery target 'immediate'
Re: Recovery target 'immediate' Re: Recovery target 'immediate' |
Список | pgsql-hackers |
On Fri, Apr 26, 2013 at 1:47 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 26 April 2013 11:29, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > >> But there is also an operation to simply "restore a backup". > > Just because a tool supports an imprecise definition of a restore, > doesn't mean Postgres should encourage and support that. > > "Restore a backup" is more suited to filesystems where most files > don't change much. And its also a common user complaint: "I restored > my back but now I've lost my changes. Can you help?". That's not > something that's been heard around here because we don't encourage > foot-guns. I think it makes perfect sense to have this. Since we do guarantee it to still be consistent even if things *are* changing around. The lack of an easy way to do this is probably the most common reason I've seen for people using pg_dump instead of physical backups in the past. pg_basebackup fixed it for the backup side of things, with the -x option. This appears to be a suggestion to do that kind of restore even if you have a log archive style backups. That said, maybe the easier choice for a *system* (such as v-thingy) would be to simply to the full backup using pg_basebackup -x (or similar), therefor not needing the log archive at all when restoring. Yes, it makes the base backup slightly larger, but also much simpler... As a bonus, your base backup would still work if you hosed your log archive. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: