Re: Minimizing Recovery Time (wal replication) - Mailing list pgsql-general

From Greg Smith
Subject Re: Minimizing Recovery Time (wal replication)
Date
Msg-id alpine.GSO.2.01.0904092005090.12261@westnet.com
Whole thread Raw
In response to Re: Minimizing Recovery Time (wal replication)  (Bryan Murphy <bmurphy1976@gmail.com>)
Responses Re: Minimizing Recovery Time (wal replication)
List pgsql-general
On Thu, 9 Apr 2009, Bryan Murphy wrote:

>> 1) Decrease the maximum possible segment backlog so you can never get this
>>   far behind
>
> I understand conceptually what you are saying, but I don't know how to
> practically realize this. :)  Do you mean lower checkpoint_segments?

Theoretically, every time the archive_command writes a new segment out you
can immediately move that to your standby, and setup the standby to
regularly look for those and apply them as they come in.  The fact that
you're getting so many of them queued up suggests there's something in
that path that isn't moving that pipeline along aggressively enough,
without knowing more about what you're doing it's hard to say where that
is.

> It actually is an 8 drive raid 10, BUT, it's on virtualized
> infrastructure up in Amazon's cloud running on 8 EBS volumes.  I've
> found performance to be... inconsistent at best.

Yeah, EBS is not exactly a high-performance or predictable database
storage solution, particularly when you get to where you're calling fsync
a lot--which is exactly what is happening during the period you note your
system is frozen.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

pgsql-general by date:

Previous
From: Bryan Murphy
Date:
Subject: Re: Minimizing Recovery Time (wal replication)
Next
From: linnewbie
Date:
Subject: Re: Storing HTML: HTML entities being rendered in that raw form