From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Patrick B <patrickbakerbr(at)gmail(dot)com> |
Cc: | Venkata B Nagothi <nag1010(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Wal files - Question | Postgres 9.2 |
Date: | 2016-11-25 01:21:56 |
Message-ID: | CAB7nPqR89mZApPar33+3C1RXuBLoS3XxEg=8Yvg9Mm-XscEeOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Nov 25, 2016 at 10:05 AM, Patrick B <patrickbakerbr(at)gmail(dot)com> wrote:
> If I get messages like:
>
> cp: cannot stat '/walfiles/0000000200001AF8000000A5': No such file or
> directory
>
> In my head, it's saying that it was unable to recover that file and, because
> of that, there is missing data.
> Even if the server is able to connect to tbe master via streaming
> replication, there might be missing data. There might be data that is into
> master but not into slave.
>
> Am I wrong? If so, I don't understand why are the wal_files for, then.
In order, a startup process will look for a WAL segments in its local
pg_xlog, then using restore_command, and finally via streaming
(XLogPageRead in xlog.c). If streaming fails, because for example the
segment requested has already been recycled, then startup process
switches back to a lookup in archive/pg_xlog. If you happen to have
repetitive failures with restore_command, you are missing a segment
and the standby would not be able to replay further. If the segment is
indeed missing, a new base backup is the way to go. A standby without
the WAL segments to replay is useless except if you plan to use PITR
and restore to a position before the last segment available in its
timeline history.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | rob stone | 2016-11-25 01:34:46 | Re: query locks up when run concurrently |
Previous Message | Patrick B | 2016-11-25 01:05:59 | Re: Wal files - Question | Postgres 9.2 |