Re: hot standby lagging vs warm that is up-to-date

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: MirrorX <mirrorx(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: hot standby lagging vs warm that is up-to-date
Date: 2012-08-29 15:11:52
Message-ID: 10235.1346253112@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

MirrorX <mirrorx(at)gmail(dot)com> writes:
> i am facing a rather 'weird' issue so please if you have ideas/thoughs share
> them.

> i have a setup of a master server and hot standby one. the database settings
> on both are identical, the specs of the servers are the same except of the
> disks. the disks on the standby are much slower than the master's.

That is not a good situation to be in. Replay of WAL logs is typically
less efficient than original creation of them (there are various reasons
for this, but the big picture is that the replay environment can't use
as much caching as a normal server process). If the master's workload
is mostly-write then you need a slave with at least the same spec I/O
system, or it's very likely to fall behind.

> the problem is that during the apply of the archives, sometimes the process
> is being 'stuck' for too long on some archives (maybe even more than 30
> minutes for a single archive or even 2 hours on some occasions). at that
> point, running an 'iostat' command shows one of the disks(not always the
> same disk) being used 100%.

Hm. Can you get a stack trace of the startup process when it's doing
that?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-08-29 15:20:44 Re: BUG #7509: x NOT IN (select x from z) extremely slow in compare to select x from y except select x from z;
Previous Message Merlin Moncure 2012-08-29 13:55:46 Re: BUG #6489: Alter table with composite type/table