Date: Thu, 26 Feb 2015 11:11:52 -0500
From: "David F. Skoll" <dfs@roaringpenguin.com>
To: pgsql-admin@postgresql.org
Cc: John Scalia <jayknowsunix@gmail.com>
Subject: Re: Weird spikes in delay for async streaming replication
 on 9.1
Message-ID: <20150226111152.3e0e28c8@hydrogen.roaringpenguin.com>
In-Reply-To: <54EF449A.9030407@gmail.com>
References: <20150214110050.2f032f05@ollie.roaringpenguin.com>
 <20150226094428.34531376@hydrogen.roaringpenguin.com>
 <54EF3E6F.60403@gmail.com>
 <20150226104433.1b0df1db@hydrogen.roaringpenguin.com>
 <54EF411B.80202@gmail.com>
 <20150226110007.09bb1551@hydrogen.roaringpenguin.com>
 <54EF449A.9030407@gmail.com>
Organization: Roaring Penguin Software Inc.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

On Thu, 26 Feb 2015 11:06:50 -0500
John Scalia <jayknowsunix@gmail.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.


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin