From: Manoj Govindassamy <manoj@nimblestorage.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-general@postgresql.org
Cc: pgsql-admin@postgresql.org
Subject: Re: PG synchronous replication and unresponsive slave
Date: Tue, 17 Jan 2012 13:37:51 -0800
Message-ID: <4F15EA2F.2040703@nimblestorage.com> (raw)
In-Reply-To: <CAHGQGwH5R-iinVkQgmsnUOJJpczY6c-xkwBtcs+wfw9MjzVCNQ@mail.gmail.com>
References: <4F0E0438.5070300@nimblestorage.com>
<4F0F229F.30308@nimblestorage.com>
<4F1471AB.9060008@nimblestorage.com>
<CAHGQGwH5R-iinVkQgmsnUOJJpczY6c-xkwBtcs+wfw9MjzVCNQ@mail.gmail.com>
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.
thanks,
Manoj
On 01/16/2012 07:44 PM, Fujii Masao wrote:
> On Tue, Jan 17, 2012 at 3:51 AM, Manoj Govindassamy
> <manoj@nimblestorage.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,
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: manoj@nimblestorage.com, masao.fujii@gmail.com, pgsql-general@postgresql.org
Subject: Re: PG synchronous replication and unresponsive slave
In-Reply-To: <4F15EA2F.2040703@nimblestorage.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox