Re: replication using WAL archives - Mailing list pgsql-admin

From Gaetano Mendola
Subject Re: replication using WAL archives
Date
Msg-id 4179729A.5020401@bigfoot.com
Whole thread Raw
In response to Re: replication using WAL archives  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-admin
Simon Riggs wrote:
> Situation I thought I saw was:>> - copy away current partial filled xlog N> - xlog N fills, N+1 starts> - xlog N+1
fills,N+2 starts> - copy away current partial filled xlog: N+2 (+10 secs later)>> i.e. if time to fill xlog (is ever) <
timeto copy away current xlog,> then you miss one.>> So problem: you can miss one and never know you've missed one
untilthe> recovery can't find it, which it never returns from...so it just hangs. 

No. The restore.sh is not smart enough to know the last wal that must be
replayed, the only "smart thing" is to copy the supposed "current wal" in the
archive directory.

The script hang (and is a feature not a bug) if and only if the master is alive
( at least I'm not seeing any other hang ).

In your example in the archived directory will be present the files until logN
and logN+2 ( the current wal ) is in the partial directory, if the master die,
the restore.sh will copy logN+2 in the archived directory, the spare node will
execute restore.sh with file logN+1 as argument and if is not found then the
restore.sh will exit.


Regards
Gaetano Mendola









pgsql-admin by date:

Previous
From: Devrim GUNDUZ
Date:
Subject: Re: RPM vs. Compile benefits?
Next
From: Thomas Swan
Date:
Subject: Re: About System Catalogs