From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "'Paula Price *EXTERN*'" <pj8abug(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Postgresql 9.2 has standby server lost data? |
Date: | 2015-06-22 08:04:20 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B50F66F9A@ntex2010a.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Paula Price wrote:
> I have Postgresql 9.2.10 streaming replication set up with log shipping in
> case the replication falls behind. I discovered that the log-shipping had
> been disabled at some point in time. I enabled the log shipping again.
>
> If at some point in time the streaming replication fell behind and the
> standby server was not able to retrieve the necessary WAL file(s) from the
> primary, would the standby server continue to function normally? Do I need
> to rebuild the standby server? I have restarted the standby server and it
> is up and running with no issues. I need to know if the
> data integrity has been compromised.
>
> I have run this query to determine the lag time for the standby(in case
> this tells me anything):
> "SELECT now(), now() - pg_last_xact_replay_timestamp() AS time_lag;
> RESULT:
> "2015-06-19 00:40:48.83701+00";"00:00:01.078616"
Your were lucky and replication did not fall behind.
If it had, and replication had tried to resort to WAL archives,
replication would have got stuck there.
There is no way that recovery can omit a portion of WAL during replay.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2015-06-22 08:13:22 | Re: Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux |
Previous Message | Albe Laurenz | 2015-06-22 08:00:40 | Re: INSERT a number in a column based on other columns OLD INSERTs |