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@xxxxxxxxxx
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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
