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: | Raw Message | Whole Thread | 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 |