Skip site navigation (1) Skip section navigation (2)

Re: equivalent to "replication_timeout" on standby server

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Samba <saasira(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: equivalent to "replication_timeout" on standby server
Date: 2011-11-07 02:51:04
Message-ID: (view raw or whole thread)
Lists: pgsql-general
On Fri, Nov 4, 2011 at 10:58 PM, Samba <saasira(at)gmail(dot)com> wrote:
> although both master(with replication_timeout)  and slave (with tcp timeout
> option in primary_conninfo parameter) closes the connection in quick time
> (based on tcp idle connection  timeout), as of now they do not log such
> information. It would be really helpful if such disconnects are logged with
> appropriate severity so that the problem can identified early and help in
> keeping track of patterns and history of such issues.

Oh, really? Unless I'm missing something, when replication timeout happens,
the following log message would be logged in the master:

    terminating walsender process due to replication timeout

OTOH, something like the following would be logged in the standby:

    could not receive data from WAL stream......

> Presently, neither master nor standby server attempts to resume streaming
> replication when they happen to see each other after some prolonged
> disconnect. It would be better if either master or slave or both the servers
> makes periodic checks to find if the other is reachable and resume the
> replication( if possible, or else log the message that a full sync may be
> required).

The standby periodically tries reconnecting to the master after it detects
the termination of replication connection. So even after prolonged disconnect,
replication can automatically resume.


Fujii Masao
NTT Open Source Software Center

In response to

pgsql-general by date

Next:From: Fujii MasaoDate: 2011-11-07 04:27:07
Subject: Re: Streaming Replication woes
Previous:From: Tomas VondraDate: 2011-11-07 00:26:54
Subject: Re: Named / preparsed / preplaned(prepared) queries - Feature proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group