Tom, thanks for the advice. I brought up a new instance yesterday, with the intent of trying it, and discovered that Wal-e with the "blind-restore" option would put everything in the pg_tblspc directory, instead of symlinking it. For this use case, that worked great.
Nate On Wed, Jul 20, 2016 at 11:16 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Nate Dudenhoeffer <ndudenhoef...@gmail.com> writes: > > The issue is that both clusters are using a base_backup and wal restore > > from the same master database, so when they are restored, the tablespace > > will already exist. Is there a way to change the tablespace location > during > > the recovery process? > > You would definitely need each slave to have its own copy of the > tablespace. I've not done this myself and would strongly recommend > testing on non-production instances, but I believe you can make it work > by adjusting each slave's $PGDATA/pg_tblspc symlinks to point to different > locations. When setting up new slave instances, pg_basebackup's > --tablespace-mapping option would help you with that. For an existing > slave instance, you'd need to shut it down while manually moving the > tablespace directory(s) and re-pointing the symlink(s). > > regards, tom lane >
