Re: Automatic Client Failover - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: Automatic Client Failover
Date
Msg-id 4899CB73.6020005@bluegap.ch
Whole thread Raw
In response to Re: Automatic Client Failover  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Hi,

Dimitri Fontaine wrote:
> That's not exactly this, I want to preserve any of the database servers from 
> erroring whenever a network failure happens. Sync is not an answer here.

So, you want your base data to remain readable on the slaves, even if it 
looses connection to the master, right?

However, this is not dependent on any timing property of replication of 
writing transaction (i.e. sync vs async). Instead, it's very well 
possible for any kind of replication solution, to continue allowing 
read-only access to nodes which lost connection to the primary or to the 
majority of the cluster. Such a node will fall behind with its snapshot 
of the data, if the primary continues writing.

> That's exactly it: I'm not using replication as a way for a slave to takeover 
> the master in case of failure, but to spread data availability where I need 
> it, and without requiring a central server to be accessible (SPOF).

I understand. So this is increasing "read-only availability", sort of, 
which is what's possible with today's tools. I'm still claiming that you 
rather want to increase overall availability, once that's possible. But 
arguing about inexistent solutions is pretty pointless.

> But as you mention it, we 
> don't yet have a multi-master production setup.
> 
> I still hope it'll get on the radar sooner than later, though ;)

Well, it's certainly on *my* radar ;-)

Regards

Markus Wanner


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Parsing of pg_hba.conf and authenticationinconsistencies
Next
From: "Hiroshi Saito"
Date:
Subject: Re: unable to build libpq on Win 2003 (32 bit)