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

Поиск
Список
Период
Сортировка
От Toby Corkindale
Тема Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reportsunlikely, very large delays
Дата
Msg-id 679631248.285932.1490324595264.JavaMail.zimbra@strategicdata.com.au
обсуждение исходный текст
Ответ на Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays  (John DeSoi <desoi@pgedit.com>)
Список pgsql-general
----- Original Message -----
> > 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 the file until it is full (16MB,
> if I recall correctly). To address this, you can change the archive_timeout
> setting to ensure the WAL file is sent at some interval even if it is not
> full.

Apologies, I should have mentioned. We're using streaming replication.



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

Предыдущее
От: John DeSoi
Дата:
Сообщение: Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [GENERAL] Lag in asynchronous replication