Re: Updated backup APIs for non-exclusive backups
От | David Steele |
---|---|
Тема | Re: Updated backup APIs for non-exclusive backups |
Дата | |
Msg-id | a31088f4-2251-8f53-8565-f39f651a3d68@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Updated backup APIs for non-exclusive backups (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Updated backup APIs for non-exclusive backups
|
Список | pgsql-hackers |
On 11/26/18 12:31 AM, Laurenz Albe wrote: > On Sun, 2018-11-25 at 16:04 -0500, Stephen Frost wrote: >>>> There isn’t any need to write the backup label before you restore the database, >>>> just as you write recovery.conf then. >>> >>> Granted. >>> But it is pretty convenient, and writing it to the data directory right away >>> is a good thing on top, because it reduces the danger of inadvertedly >>> starting the backup without recovery. >> >> Writing it into the data directory is *not* a good thing because as soon as you do >> that you risk there being an issue if there’s a crash. Writing into the backup >> isn’t a bad idea but if you’re managing your backups then writing it somewhere else >> (such as where you write your WAL) and associating it with the backup (presumably >> it has a label) should make it easy to pull back when you restore. > > If there is a crash during the backup procedure, the backup is bad. > Doesn't matter during which part of the backup procedure it happens. Yes, but in this case with exclusive backups your cluster also will not start. That's a lot different than a bad backup because you should have many backups and a way to mark when they are complete. If your cluster requires manual intervention to start because a backup was in progress that's not a good thing. I'm of the opinion that we should remove the exclusive option for PG12. The recovery changes recently committed will completely break any automated recovery written for PG <= 11 so we might as go all the way. Requiring non-exclusive backup will be an easy change for tools that already understand non-exclusive backup, which has been available in the last three versions of Postgres. The exclusive backup method tries to make a hard problem look simple but does not succeed and causes issues besides. Performing backups properly *is* hard and we don't do anyone a service by making it look like something can be done with a trivial bash script. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: