Re: WAL log shipping + Streaming replication PG 9.0 questions - Mailing list pgsql-admin

From Robert Treat
Subject Re: WAL log shipping + Streaming replication PG 9.0 questions
Date
Msg-id AANLkTimEbGyyVAytVhjug_6zC9hEhbh7k01UxvkaDQZz@mail.gmail.com
Whole thread Raw
In response to Re: WAL log shipping + Streaming replication PG 9.0 questions  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-admin
On Tue, Oct 19, 2010 at 10:40 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Tue, Oct 19, 2010 at 11:46 PM, Isabella Ghiurea
> For the last question I ' m still a bit confused: if master_archive off line
> ( no archived WAL's available) what will be state of  standby server ?
> Basically we are trying to design a solution where WAL archived directory is
> not a "single point of failure"   for whole system ( we are planing to have
> WAL archived master directory on a separate machine and both server primary
> and standby will have read/write here) if this servers fails , we  want  to
>  be able to continue normal user operation on master while standby server
>  will have some latency.

You have three machines, the first is the master, the second is the standby,
and the last is something like NAS which has the archive area shared by them.
Right?

Even if the archive is unavailable, we can continue normal user operation
like INSERT/UPDATE/DELETE on the master until its pg_xlog has run out of
disk space (As I said before, a failure of archive_command continues to
accumulate unarchived WAL files in pg_xlog). So, you would need to check
periodically whether the archive is available or not by using a monitoring
tool, in order to prevent pg_xlog from running out of disk space.

On the other hand, even if the archive is unavailable, if the replication
connection is alive, the standby can receive the WAL and catch up with the
master. But, if the replication connection is terminated and the standby
cannot connect to the master because of the network outage, the standby can
read no WAL from neither the master nor the archive. In this case, the
standby would fall behind the master.

Just to chime in here, this doesn't necessarily have to "break" your standby; rather it can happily sit around waiting for the next xlog to show up. If you can fix connectivity to the NAS, it will happily start replaying log files and catching up again. 

Robert Treat

pgsql-admin by date:

Previous
From: Fujii Masao
Date:
Subject: Re: WAL log shipping + Streaming replication PG 9.0 questions
Next
From: Kieren Scott
Date:
Subject: Re: Restricting schema sizes