Date: Wed, 31 Aug 2016 16:22:22 -0400
From: Dianne Skoll <dfs@roaringpenguin.com>
To: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: What causes streaming replication delay? [SOLVED, I
 think]
Message-ID: <20160831162222.21288e76@hydrogen.roaringpenguin.com>
In-Reply-To: <20160831131604.0f305404@hydrogen.roaringpenguin.com>
References: <20160831114417.7fc1040d@hydrogen.roaringpenguin.com>
	<CAHw75vtu-Mxjp1uFB1iQctnT9Tew72=OgBE9sVO4mW+kHZEDKw@mail.gmail.com>
	<20160831131604.0f305404@hydrogen.roaringpenguin.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

Hi,

I think I solved it.  This is so ridiculous!

The primary and standby databases are 200km apart and the path between them
has a bandwidth of only 100 Mb/s.  We had bursts of writes that created
huge amounts of replication traffic.  In addition to streaming
replication, we're still copying WAL files over for safety (and also
because this is 9.1...)

We were hitting our bandwidth limit.

By adding the --bwlimit parameter to the rsync command that copies the WAL
files, we can limit the bandwidth usage during the bursts while still
keeping it high enough for the WAL-file archiving to keep up on average.

Keeping an eye on it for 24h before I completely declare it solved.

Regards,

Dianne.


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