Re: [Skytools-users] WAL Shipping + checkpoint

Поиск
Список
Период
Сортировка
От Sébastien Lardière
Тема Re: [Skytools-users] WAL Shipping + checkpoint
Дата
Msg-id 4A967724.7030704@hi-media.com
обсуждение исходный текст
Ответ на Re: [Skytools-users] WAL Shipping + checkpoint  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Ответы Re: [Skytools-users] WAL Shipping + checkpoint
Список pgsql-general
On 27/08/2009 00:18, Mark Kirkwood wrote:
> Sébastien Lardière wrote:
>> On 26/08/2009 04:46, Mark Kirkwood wrote:
>>> Sébastien Lardière wrote:
>>>> Hi All,
>>>>
>>>> I've a cluster ( Pg 8.3.7 ) with WAL Shipping, and a few hours ago,
>>>> the master had to restart.
>>>>
>>>> I use walmgr from Skytools, which works very well.
>>>>
>>>> I have already restart the master without any problem, but today,
>>>> the slave doesn't work like I want. The field "Time of latest
>>>> checkpoint" from the pg_controldata on the slave keep the same
>>>> values, but WAL File are processed correctly.
>>>>
>>>> I try to restart the slave, but, after processed again all the WAL
>>>> between "Time of latest checkpoint" and, it does nothing else,
>>>> latest checkpoint stay at the same value.
>>>>
>>>> I don't know if it's important ( i think so ), and I can't fix it.
>>>>
>>> It is normal for it to lag behind somewhat on the slave (depending
>>> on what your checkpoint timeout etc settings are).
>>>
>>> However, I've noticed what you are seeing as well - particularly
>>> when there are no actual data changes coming through in the logs -
>>> the slave checkpoint time does not change even tho there have been
>>> checkpoints on the master (I may have a look in the code to see what
>>> the story really is...if I have time).
>>>
>>
>> Yes, but the delay between the last checkpoint on the master and the
>> slave is very high, now ( 100 000 sec ), because the last checkpoint
>> on the slave was yesterday ( as far as pg_controldata is right )
>>
>> Here a graph from our munin plugin :
>> http://seb.ouvaton.org/tmp/bdd-pg_walmgr-week.png
>>
>> The blue line represent an average between two WAL processed on the
>> slave, and the green line, the delai between last checkpoint on the
>> master and the slave.
>>
>> Maybe it's not some good indicator, but the green line let me think
>> there is problem.
>>
>>
> Do you have archive_timeout set? If so, then what *could* be happening
> is this:
>
> There are actually no "real" data changes being made on your master
> for some reason. So every time archive_timeout is reached a log full
> of no changes is shipped to your slave and applied - and no checkpoint
> times are changed for reasons I mentioned above.
>
>

thanks, but we have not set archive_timeout, and we have a lot of real
data changes.

That's why i don't understand why checkpoint never happen on the slave.

--
Sébastien Lardière



В списке pgsql-general по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: PG 8.2 instal on Win2k3 - unable to connect to test network socket
Следующее
От: Kelly Jones
Дата:
Сообщение: Viable alternatives to SQL?