From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | hans wulf <lotu1(at)gmx(dot)net> |
Cc: | Michael Nolan <htfoot(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: 9.1.3 Standby catchup mode |
Date: | 2012-04-08 23:41:31 |
Message-ID: | 4F82222B.4040902@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 04/08/2012 03:51 AM, hans wulf wrote:
>> Why would you not want to maintain a WAL archive? Are you depending on
>> the
>> slave server(s) as your only form of backup?
>
> If the slave devide acts as a perfect backup, why would I need an additional 3rd entiy for WAL backups?
Belt and suspenders mode:). Assuming you archive the WAL files to a
third machine and there is independent connection from that machine to
the standby, the standby will pick up the data from those WAL files if
it loses its streaming connection to the primary and the primary is
still up and generating WAL files. This would depend on you setting up
file archiving from the primary to the third machine and archive
retrieval from the third machine to the standby. What you get is a
history of WAL files that you can replay should the streaming link go
down. Basically a second copy of the primary.
>
> I know what the difference between sync and async is, but I don't see the need for a WAL archive in sync mode. Can you please explain that? Thanks
>
>
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Jasen Betts | 2012-04-09 08:40:45 | Re: Questions of the privileges to use the pg_cancel_backend and pg_terminate_backend function. Thanks. |
Previous Message | hans wulf | 2012-04-08 10:51:04 | Re: 9.1.3 Standby catchup mode |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-04-09 01:37:23 | bug in fast-path locking |
Previous Message | Peter Geoghegan | 2012-04-08 23:00:34 | Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |