From: | Neil Worden <nworden1234(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: naming of wal-archives |
Date: | 2013-02-01 10:15:01 |
Message-ID: | CADZZMN-XbWAf=4Nf-cvx7msLqZts6tB7mTdrCR3hJPuV9KuQkQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yes, it does indeed interleave and it seems to archive the backlog just
before the files are about to be deleted. That explains it.
Thanks for your help,
Neil
2013/1/31 Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
> On Thu, Jan 31, 2013 at 12:50 AM, Neil Worden <nworden1234(at)gmail(dot)com>
> wrote:
> >
> > The situation is as follows:
> >
> > All concerned machines are running 9.2.2 64-bit on Ubuntu Linux Server
> > 12.10, installed from source, all following exactly the same procedure.
> We
> > have a hot-standby running to a different location over a rather thin
> line
> > running since version 9.1 came out. That worked
> > flawlessly, we only were bitten by autovacuums to prevent XID wraparounds
> > that generated relatively high wal-volume and we
> > were not sure whether the network connection could keep up with it before
> > deleting wal-files. Since we had to physically transfer a backup once for
> > other reasons, we set wal_keep_segments to 8192 to have enough
> > fallback-time.
>
> Ah.
>
> ...
> >
> > Could the the high number of wal_keep_segments have an impact ?
> > Does the fact that there already were a lot of existing wal-files when i
> set
> > up archiving and the archive-command have an impact ?
>
> Yes. It is doing something like archiving the newly-finished log
> files as they are completed, and interleaving that with working off
> the wal_keep_segments backlog. So everything seems normal. At some
> point they should converge without difficulty.
>
> >
> > Jeff, you wrote:
> >
> >>> And how would i restore the needed file names for recovery
> >>> if i decide to keep one base-backup und then a very long chain of
> >>> wal-files
> >>> ?
> >
> >>There should be no need for that.
> >
> > When you said there would be no need for that, did you mean restoring the
> > files for recovery or keeping a base-backup and the chain of wal-files ?
>
> No, you need both of those. There should be no need to restore the
> *names* of the files. It sounded like you were planning to invent
> some scheme to rename files and rename them back.
>
> >
> > I understand that the archive-command is responsible for not overwriting
> > wal-files. But if that situation occurs, and if i understand you
> correctly
> > it will, what do i do ?
>
> If it attempts to overwrite, refuses and returns with a non-zero
> status, then your server will accumulate unarchived log files in
> pg_xlog and you will get warnings in the log file something like:
>
> LOG: archive command failed with exit code 1
>
> It will keep trying, but of course also keep failing, until you
> manually intervene.
>
> The risks are that pg_xlog might fill up, or that if the hard drive
> that holds pg_xlog crashes you will lose log files that were scheduled
> to have been archived but never made it there.
>
> But, this should be a moot point if you indeed only have one server
> archiving to that directory.
>
> Although this has happened to me a couple times, and I just renamed
> the offending archived file to something else (i.e. add .bak to the
> name) to unblock the process. And then compare to moved file to the
> newly arrived archival of it and verify that they were identical (they
> were). Apparently what happened was that a network glitch caused the
> file copy think it failed when it had not. Then future attempts
> failed because the file already existed.
>
> Cheers,
>
> Jeff
>
From | Date | Subject | |
---|---|---|---|
Next Message | hamann.w | 2013-02-01 10:22:00 | Re Deleting 173000 records takes forever |
Previous Message | Vlad Bailescu | 2013-02-01 09:54:39 | Re: Unusually high IO for autovacuum worker |