Re: Remove Deprecated Exclusive Backup Mode
От | Adrien NAYRAT |
---|---|
Тема | Re: Remove Deprecated Exclusive Backup Mode |
Дата | |
Msg-id | 319af73b-ac64-47fa-0246-af7291d3f3d6@anayrat.info обсуждение исходный текст |
Ответ на | Re: Remove Deprecated Exclusive Backup Mode (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Remove Deprecated Exclusive Backup Mode
|
Список | pgsql-hackers |
On 2/22/19 7:10 PM, Robert Haas wrote: > On Fri, Feb 22, 2019 at 12:35 PM Fujii Masao <masao.fujii@gmail.com> wrote: >> -1 for the removal. I think that there are still many users of an exclusive >> backup API, and it's not so easy to migrate their backup scripts so that >> only non-exclusive one is used because of the reason I wrote in another thread. >> https://postgr.es/m/CAHGQGwHUkEbkVexVfWNLjmq2rzOS_SHYMiECt+KBn-cBPq5Arg@mail.gmail.com > > Yeah, those are interesting points. Unfortunately, I think something > as simple as your proposed... > > psql -c "SELECT pg_start_backup()" > rsync, cp, tar, storage backup, or something > psql -c "SELECT pg_stop_backup()" > > ...doesn't have much chance of being correct. If you aren't checking > whether pg_start_backup() throws an error, for example, you have got a > very failure-prone set-up. That being said, it's possible to fix that > problem using some shell logic, whereas the problem of keeping a > connection open for the duration of the backup from the shell is much > harder. I recently ran across a case where someone attempted it but > did not get the logic entirely right, with rather painful > consequences. > > Now you might say that people should not write their own tools and > just use professionally produced ones. But I don't really agree with > that, and whatever we think people SHOULD do, there are in fact a lot > of people using their own tools. > FWIW +1 for not remove exclusive backup. Maintain a connection during the backup is a hard pre-requisite. In my previous jobs I already done custom scripts to perform backup by using pre/post backup hook to control backup software: With vmware to do PITR backup with VM snapshot or with another file backup tool which perform block deduplication. I do not see where is the problem if you check pg_start_backup()/pg_stop_backup() went well? It will be annoying if after this removal, companies must change their backup strategy by using specific postgres tools (pgbackrest, barman). Regards,
В списке pgsql-hackers по дате отправления: