Re: 9.1.3 Standby catchup mode

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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)