Re: pg_basebackup vs. Windows and tablespaces
От | Magnus Hagander |
---|---|
Тема | Re: pg_basebackup vs. Windows and tablespaces |
Дата | |
Msg-id | CABUevEyeHSvhGMupcNNRN0qxaBJUE58na0E4gcNdqaXpza+scQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_basebackup vs. Windows and tablespaces (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pg_basebackup vs. Windows and tablespaces
|
Список | pgsql-hackers |
On Mon, Aug 12, 2013 at 8:14 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > > On 08/12/2013 01:40 PM, Magnus Hagander wrote: >>>> >>>> I also like the concept of #2, but I think we need to think about it a >>>> bit more. One of the things I like about barman backups is that on >>>> recovery you can map where tablespaces go, on a per tablespace basis >>>> (it's not very well documented, or wasn't when I last looked, but it >>>> does work). I think something like that would be awesome to have for >>>> pg_basebackup. So allowing multiple options of the form >>>> >>>> --map-tablespace c:/foo/bar=d:/baz/blurfl >>>> >>>> or some such would be great. >>> >>> Good point. I see now that the syntax I floated covered just one slice >>> of a >>> whole range of things folks might want in that area. >> >> I think I have an old patch around for doing just the map-tablespace >> thing that I never quite finished. That one was mostly useful for >> setting up replicas really, since that's when you know at backup time >> where you want to the new tablespaces to go. For a regular backup, you >> want it to happen at restore time. And in this case, you're quite >> likely working off the tarfiles, and we don't really have a program >> dealing with the restore of those at all - you're just supposed to do >> it manually. >> >> A trivial tool that worked off the directory of tarfiles and allowed >> remapping of the tablespace locations (by updating the >> symlinks/junctions restored out of the base.tar flie) might be an >> easier and less invasive way to do it than to put it in the actual >> recovery code? >> >> > > > What barman does is to dissolve the symlink when making its backup (i.e > pg_tblspc/12345 becomes a directory in the backup instead of a symlink), and > store the info relating to the source symlink in its metadata file. On > restore it recreates the symlink. It's at that stage that you can modify its > default behaviour by specifying where the link should go. Something like that makes sense for a plain format dump - but maybe not for a tar one. And in either case, that also requires there to be a pg_baserestore (or whatever you'd want to call it, please come up with a better name :D) to do the restore process, to make sure it's properly mapped. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: