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

Re: PG synchronous replication and unresponsive slave

From: Manoj Govindassamy <manoj(at)nimblestorage(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>, <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PG synchronous replication and unresponsive slave
Date: 2012-01-17 21:37:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-general
Thanks for your views.

(1) Will try out emptying synchronous_standby_names on replica failures 
and verify if the transactions proceeds thru.

(2) We are not comfortable moving to PGPool just for automatic failback 
mode on hot-standby failure. Any suggestions on how to build this 
failback mechanism for master in PG9.1.2 ? We are using C interface for 
PG. Any kind of health checking that we can do on the master to detect 
the hot-standby problem and let master reload its config with empty 
synchronous_standby_names ?

Any help is much appreciated.


On 01/16/2012 07:44 PM, Fujii Masao wrote:
> On Tue, Jan 17, 2012 at 3:51 AM, Manoj Govindassamy
> <manoj(at)nimblestorage(dot)com>  wrote:
>>>> 1. Transaction which was stuck right when slave going away never went
>>>> thru even after I reloaded master's config with local commit on. I do see
>>>> all new transactions on master are going thru fine, except the one which was
>>>> stuck initially. How to get this stuck transaction complete or return with
>>>> error.
> Changing synchronous_commit doesn't affect such a transaction. Instead,
> empty synchronous_standby_names and reload the configuration file to
> resume that transaction.
>>>> 2. Whenever there is a problem with slave, I have to manually reload
>>>> master's config with local commit turned on to get master go forward. Is
>>>> there any automated way to reload this config with local commit on on
>>>> slave's unresponsiveness ? tcp connection timeouts, replication timeouts all
>>>> detect the failures, but i want to run some corrective action on these
>>>> failure detection.
> PostgreSQL doesn't have such a capability, but pgpool-II might have.
> Can you ask that in pgpool-II mailing-list?
> Regards,

In response to


pgsql-admin by date

Next:From: David SchnurDate: 2012-01-17 21:46:50
Subject: Re: Repeatable crash in pg_dump (with -d2 info)
Previous:From: Craig JamesDate: 2012-01-17 21:04:46
Subject: Re: Establishing remote connections is slow

pgsql-general by date

Next:From: Tim UckunDate: 2012-01-17 22:34:04
Subject: Re: HA options
Previous:From: John R PierceDate: 2012-01-17 21:19:23
Subject: Re: HA options

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