Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays

Поиск
Список
Период
Сортировка
От John DeSoi
Тема Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays
Дата
Msg-id 168F8EF9-301D-439E-A773-E6E20D33DBD8@pgedit.com
обсуждение исходный текст
Ответ на [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays  (Toby Corkindale <toby.corkindale@strategicdata.com.au>)
Ответы Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reportsunlikely, very large delays  (Toby Corkindale <toby.corkindale@strategicdata.com.au>)
Список pgsql-general
> On Mar 22, 2017, at 8:06 PM, Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
>
> My best guess for what is going on is:
> - There has been no activity for hours or days, and so the oldest replayed
> transaction on the slave is genuinely quite old.
> - Something has happened on the master that causes its
> pg_current_xlog_location() to be updated, but not in a way that is sent to the
> slave until the end of a long-running transaction.
>
>
> Could anyone suggest how to do this in a manner that avoids the problem?

Are you using streaming replication or only WAL archiving? If you are not streaming the archive command does not send
thefile until it is full (16MB, if I recall correctly). To address this, you can change the archive_timeout setting to
ensurethe WAL file is sent at some interval even if it is not full. 

I use 'archive_timeout = 300' to send it every 5 minutes. If the lag is greater than 15 minutes, the alarm bells start
goingoff. 

John DeSoi, Ph.D.




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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: [GENERAL] Run statements before pg_dump in same transaction?
Следующее
От: Toby Corkindale
Дата:
Сообщение: Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reportsunlikely, very large delays