On Jan 20, 2008, at 3:19 AM, Simon Riggs wrote:
> On Sat, 2008-01-19 at 13:53 -0600, Erik Jones wrote:
>
>> Here's the python script I was using to ship to both servers, right
>> now I'm back to a direct rsync call for my archive_command to sb1.
>> What's really weird, is that for the two WALs that disappeared, or
>> didn't make it, even though the primary's log said they were
>> successfully archived, they weren't on either server.
>
> Can you explain this some more? How do you know this? What messages
> are
> received relating to those files?
In my archive directory on the standby, a sorted listing has in it
this sequence:
000000010000059D00000021
000000010000059D00000023
I found this when I check the standby.log pg_standby is writing to
and found it waiting on 000000010000059D00000022. Checking the
primary server's log I found this line:
2008-01-16 04:58:41 CST 7841 :LOG: archived transaction log file
"000000010000059D00000022"
The same file was missing on the sb1 server (the one with the local
NFS mounted wal_archive directory). Since that was the local, to NFS
rsync, which I've never had any issues with, and which was preceded by
if res != 0:
sys.exit(res)
wherein the value of res comes from a remotely execute command (test
via ssh or rsync via ssh), something weird happened causing my
transfer script to exit abnormally there (or before), but Postgres
somehow saw a 0 exit status, which I understand is required in order
to get that archived transaction log file entry.
Erik Jones
DBA | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com