Re: WARNINGs after starting backup server created with PITR
От | Erik Jones |
---|---|
Тема | Re: WARNINGs after starting backup server created with PITR |
Дата | |
Msg-id | AAB8E92C-5FDF-4EA5-8120-4BD047A5E305@myemma.com обсуждение исходный текст |
Ответ на | Re: WARNINGs after starting backup server created with PITR (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: