From: | Nate Dudenhoeffer <ndudenhoeffer(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Melvin Davidson <melvin6925(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Multiple clusters with same tablespace location |
Date: | 2016-07-28 01:43:47 |
Message-ID: | CAMtF5HA6AUC+p2Cu5DMZA9XZFGT=VyJ2qf84EmY5DjAJ_r6npA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Nate Dudenhoeffer <ndudenhoeffer(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2016-07-28 02:23:18 | Re: Uber migrated from Postgres to MySQL |
Previous Message | Bruce Momjian | 2016-07-28 01:40:08 | Re: Uber migrated from Postgres to MySQL |