Re: hot standby lagging vs warm that is up-to-date - Mailing list pgsql-bugs

From Tom Lane
Subject Re: hot standby lagging vs warm that is up-to-date
Date
Msg-id 10235.1346253112@sss.pgh.pa.us
Whole thread Raw
In response to hot standby lagging vs warm that is up-to-date  (MirrorX <mirrorx@gmail.com>)
Responses Re: hot standby lagging vs warm that is up-to-date
List pgsql-bugs
MirrorX <mirrorx@gmail.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

pgsql-bugs by date:

Previous
From: Rajeev rastogi
Date:
Subject: Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus
Next
From: Tom Lane
Date:
Subject: Re: BUG #7509: x NOT IN (select x from z) extremely slow in compare to select x from y except select x from z;