From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Valentine Gogichashvili <valgog(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, senthilnathan <senthilnathan(dot)t(at)gmail(dot)com> |
Subject: | Re: Backup's from standby |
Date: | 2011-08-25 18:53:43 |
Message-ID: | CA+TgmoZJa9Ws9yEgry6rT3BnZYiKbrY5FfR=1-wD4FZsBVt5_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 19, 2011 at 9:38 AM, Valentine Gogichashvili
<valgog(at)gmail(dot)com> wrote:
>> > What issue we may face if you take a backups(includes data dir + wal
>> > files)
>> > at standby without LVM snapshot?
>>
>> The backup might be corrupted in arbitrary ways.
>
> And what will happen, if one issues a pg_start_backup() on the master, then
> takes a file-backup on slave, and issues pg_stop_backup() on master again?
> As far as I remember this approach was working for me, considering, that all
> needed WAL files are transferred to the newly created DB copy as well.
Well, I think you would need to verify a few more things:
- The pg_start_backup() will need to have been replayed on the standby
before you start the file copy.
- You will need all the WAL segments beginning at the position where
pg_start_backup() was executed on the master and ending after
pg_stop_backup() was executed on the master.
Assuming you do that, it seems like it ought to work, although I have
not tested it and am not at all sure I'm not missing something.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-08-25 19:08:10 | Re: WIP: Fast GiST index build |
Previous Message | Heikki Linnakangas | 2011-08-25 18:53:10 | Re: WIP: Fast GiST index build |