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,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
