| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Nate Dudenhoeffer <ndudenhoeffer(at)gmail(dot)com> | 
| 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-20 16:16:30 | 
| Message-ID: | 18945.1469031390@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
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 | Raymond O'Donnell | 2016-07-20 16:29:14 | Re: MediaWiki + PostgreSQL is not ready for production? | 
| Previous Message | John DeSoi | 2016-07-20 15:57:48 | Re: MediaWiki + PostgreSQL is not ready for production? |