From: vinny <vinny@xs4all.nl>
To: Anushka Weerakkodyge <anushkaw@ceylonit.com>
Cc: pgsql-admin@postgresql.org
Cc: pgsql-admin-owner@postgresql.org
Subject: Re: How to Identify and Fail Transaction When Slave Node Down
Date: Thu, 16 Mar 2017 10:51:37 +0100
Message-ID: <3e84a1a05b8af81d76953df6eb2bf8fd@xs4all.nl> (raw)
In-Reply-To: <CAMsriHZ8Sd6N3Heq_TagiFP_sOFfMkbRgkkY4foZ3TJSNH10Hw@mail.gmail.com>
References: <CAMsriHZ9jk5xkozbYfiD9asvpXQyRbsH01UZBF=XmNRg3=SRwg@mail.gmail.com>
<CAMsriHZ8Sd6N3Heq_TagiFP_sOFfMkbRgkkY4foZ3TJSNH10Hw@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
On 2017-03-16 10:06, Anushka Weerakkodyge wrote:
> Hi,
>
> problem still persists.
> Is there any configuration (parameter?) to set the timeout of the
> connection ? Because if the slave node is down, transaction to master
> node waits forever until slave node comes back online.
> Any suggestion would be highly appreciated.
>
> Thanks,
> Anushka
> On Thu, Mar 16, 2017 at 5:21 AM, Anushka Weerakkodyge
> <anushkaw@ceylonit.com> wrote:
>
>> Hi all,
>>
>> I have a synchronous streaming replication environment which is
>> implemented using inbuilt replication mechanism in postgresql.
>> Replication is working fine except I need to fail the data
>> modification transactions when the slave node is not accessible.
>>
>> Is it possible?
>>
>> Please let me know whether there is a way to identify slave node
>> status and fail the transaction using any inbuilt mechanism or some
>> other technique.
>>
>> Thanks,
>> Anushka
As far as I know, which is does not mean much, there is no timeout
setting.
And that's by design; a timeout can occur because the node is down,
but also because it's busy and cannot answer in time, or there is a
network hickup.
Adding a timeout would basically break the "syncronous" promise
because that guarantees that either all nodes are updated, or the
transaction fails.
And yes I googled this from:
https://www.postgresql.org/message-id/CADp-Sm7ENFJH4YQmJVYD2qB2OaKa6qb6TEHCJWfce%2BQoQXsdhA%40mail.g...
In the case of a node going down you should probably but some failover
mechanism in place so you can safely remove the dead node from the setup
and rebuild it before making it part of the cluster again.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
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: vinny@xs4all.nl, anushkaw@ceylonit.com, pgsql-admin-owner@postgresql.org
Subject: Re: How to Identify and Fail Transaction When Slave Node Down
In-Reply-To: <3e84a1a05b8af81d76953df6eb2bf8fd@xs4all.nl>
* 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