Re: Automatic Client Failover - Mailing list pgsql-hackers

Hi,

Dimitri Fontaine wrote:
>> Redirecting writing transactions from slaves to the master node solves
>> another problem. Being able to 'rescue' such forwarded connections in
>> case of a failure of the master is just a nice side effect. But it
>> doesn't solve the problem of connection losses between a client and the
>> master.
> 
> Agreed. It simply allows the ACF part not to bother with master(s) slave(s) 
> topology, which still looks as a great win for me.

Hm.. yeah, for master-slave replication I'm slowly beginning to see 
merit in it. However, given the lacking use of master-slave...

> Yes, you still need ACF, I'm sure I never wanted to say anything against this.

Ah, okay. I thought you were proposing an alternative.

>> IMO the only reason for master-slave replication is ease of
>> implementation. It's certainly not something a sane end-users is ever
>> requesting by himself, because he needs that "feature". After all, not
>> being able to run writing queries on certain nodes is not a feature, but
>> a bare limitation.
> 
> I'm not agreeing here.

Somehow, I just knew it..  ;-)

> I have replication needs where some data are only yo be edited by an admin 
> backoffice, then replicated to servers. Those servers also write data (logs) 
> which are to be sent to the main server (now a slave) which will compute 
> stats on-the-fly (trigger based at replication receiving).

Sure, you can currently do that because there exist master-slave 
replication solutions which can do that. And that's perfectly fine.

Comparing that with concepts of an inexistent multi-master replication 
solution is not fair by definition.




> 
> Now, this configuration needs to be resistant to network failure of any node, 
> central one included. So I don't want synchronous replication, thanks. And I 
> don't want multi-master either, as I WANT to forbid central to edit data from 
> the servers, and to forbid servers to edit data coming from the backoffice.
> 
> Now, I certainly would appreciate having the central server not being a SPOF 
> by having two masters both active at any time.
> 
> Of course, if I want HA, whatever features and failure autodetection 
> PostgreSQL gives me, I still need ACF. And if I get master/slave instead of 
> master/master, I need STONITH and hearbeat or equivalent.
> I was just trying to propose ideas for having those external part as easy as 
> possible to get right with whatever integrated solution comes from -core.
> 
>> In your question, you are implicitly assuming an existing multi-master
>> implementation. Given my reasoning, this would make an additional
>> master-slave replication pretty useless. Thus I'm claiming that such a
>> configuration does not make sense.
> 
> I disagree here, see above.
> 
>> Huh? AFC for master-slave communication? That implies that slaves are
>> connected to the master(s) via libpq, which I think is not such a good fit.
> 
> I'm using londiste (from Skytools), a master/slaves replication solution in 
> python. I'm not sure whether the psycopg component is using libpq or 
> implementing the fe protocol itself, but it seems to me in any case it would 
> be a candidate to benefit from Simon's proposal.
> 
> Regards,