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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: hot standby lagging vs warm that is up-to-date
Дата
Msg-id 10235.1346253112@sss.pgh.pa.us
обсуждение исходный текст
Ответ на hot standby lagging vs warm that is up-to-date  (MirrorX <mirrorx@gmail.com>)
Ответы Re: hot standby lagging vs warm that is up-to-date
Список 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 по дате отправления:

Предыдущее
От: Rajeev rastogi
Дата:
Сообщение: Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #7509: x NOT IN (select x from z) extremely slow in compare to select x from y except select x from z;