Re: Starting new cluster from base backup
От | Adrian Klaver |
---|---|
Тема | Re: Starting new cluster from base backup |
Дата | |
Msg-id | 54E519F6.1080907@aklaver.com обсуждение исходный текст |
Ответ на | Re: Starting new cluster from base backup (Guillaume Drolet <droletguillaume@gmail.com>) |
Список | pgsql-general |
On 02/18/2015 01:48 PM, Guillaume Drolet wrote: > > > > > So if I understand correctly you have: > > 1) On source machine a directory E:\Data\Database. > 2) On the source machine in Postgres you have a created a tablespace > that points at E:\Data\Database. > 3) On destination machine you have an E:\ drive also. > > You're correct > > Then have you tried: > > 1) Create \Data\Database directory under E:\ on the destination machine. > > 2) Do the pg_basebackup. > > > I'm not sure I understand why, at this moment in the sequence of > operation, I would create \Data\Database under E:\ on the destination > machine. > pg_basebackup, when run on the source DB on the source machine, has no > idea about the destination machine. Maybe you're confused with the F:\ > drive, which is the drive on which I tried to save my base backup with > the command: I am confused, but not about F:\ drive:). My confusion was on where the error "directory "E:\Data\Database" exists but is not empty" occurred. I just ran a test. So the issue is in plain mode pg_basebackup does the binary copy to F:\208376PT\db which is fine. The problem is that it can still see E:\Data\Database on the source machine, so when it tries to set up the copy of the tablespace it sees that the directory is not empty and stops. So the only way this going to work in 9.3 with plain is to copy not to F:\ but to the destination machine directly. I am guessing that is not possible? It works in the tar case because the tablespace directory gets renamed. > > pg_basebackup -D "F:\208376PT\db" -X stream -l "208376PT17022015" -U > postgres -P > > This drive (F:\) is not the destination machine, it's a swappable disk I > use to move my base backup from one machine (the source) to another (the > destination). > > > I have not done it and I see the "Although not recommended.." part > above, so I would say that is a last resort solution. > > > I confirm this method works. I've done it in the past using the steps in > this blog and its comments: > > http://www.databasesoup.com/2013/11/moving-tablespaces.html Interesting post, I missed it the first time around. Seems worth a try. > > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: