Re: Automatic Client Failover

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,