| From: | "David F(dot) Skoll" <dfs(at)roaringpenguin(dot)com> | 
|---|---|
| To: | pgsql-admin(at)postgresql(dot)org | 
| Cc: | John Scalia <jayknowsunix(at)gmail(dot)com> | 
| Subject: | Re: Weird spikes in delay for async streaming replication on 9.1 | 
| Date: | 2015-02-26 16:11:52 | 
| Message-ID: | 20150226111152.3e0e28c8@hydrogen.roaringpenguin.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-admin | 
On Thu, 26 Feb 2015 11:06:50 -0500
John Scalia <jayknowsunix(at)gmail(dot)com> wrote:
> Possibly, but that's why WE use a pair of standby servers, not a
> single one, so that all transactions get committed in a timely
> manner. The odds of both standbys failing at the same time are really
> small. Maybe your script should check which is latest WAL segment on
> each system first? That might show that you have a timedelay with
> getting the info to the standby.
That doesn't seem to be a problem. When I run this:
watch -n 0.1 'ps auxww|grep [w]al.*streaming'
on both primary and standby, the ID number after "streaming" increments
on both smoothly; there's no significant pause even when the delay starts
growing.
Regards,
David.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Scalia | 2015-02-26 16:15:51 | Security with V9.3.3 standby servers | 
| Previous Message | John Scalia | 2015-02-26 16:06:50 | Re: Weird spikes in delay for async streaming replication on 9.1 |