Re: pg_basebackup vs. Windows and tablespaces
От | Magnus Hagander |
---|---|
Тема | Re: pg_basebackup vs. Windows and tablespaces |
Дата | |
Msg-id | CABUevEySHuigZRWs1FDRMiQWzsd6Dz9Hft36YWvCLGPaf6RyMg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_basebackup vs. Windows and tablespaces (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: pg_basebackup vs. Windows and tablespaces
(Andrew Dunstan <andrew@dunslane.net>)
|
Список | pgsql-hackers |
On Mon, Aug 5, 2013 at 10:03 PM, Noah Misch <noah@leadboat.com> wrote: > On Thu, Aug 01, 2013 at 01:04:42PM -0400, Andrew Dunstan wrote: >> On 08/01/2013 12:15 PM, Noah Misch wrote: >>> 1. Include in the base backup a file listing symbolic links/junction points, >>> then have archive recovery recreate them. This file would be managed like the >>> backup label file; exclusive backups would actually write it to the master >>> data directory, and non-exclusive backups would incorporate it on the fly. >>> pg_basebackup could also omit the actual links from its backup. Nearly any >>> tar or file copy utility would then suffice. >>> >>> 2. Add a pg_basebackup option like "--destdir" or "--sysroot", meaningful only >>> with -Fp; tablespace backups will be stored relative to it. So if the actual >>> tablespace path is c:/foo, --destdir=c:/backups/today would backup that >>> tablespace to c:/backups/today/c/foo. This facilitates same-server use of -Fp >>> on all platforms. > >> I like #1, it seems nice and workable. > > Agreed. I'll lean in that direction for resolving the proximate problem. +1. >> 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? -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: