Re: Automatic Client Failover

Le mardi 05 août 2008, Markus Wanner a écrit :
> I do not understanding that reasoning. Synchronous replication is
> certainly *more* resilient to network failures, as it does *not* loose
> any data on failover.
>
> However, you are speaking about "logs" and "stats". That certainly
> sounds like data you can afford to loose during a failover, because you
> can easily recreate it. And as asynchronous replication is faster,
> that's why you should prefer async replication here, IMO.

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.

> Well, I'd say you are (ab)using replication as an access controlling
> method. That's not quite what it's made for, but you can certainly use
> it that way.

The fact that I need those controls led me to this replication design.

> As I understand master-slave replication, a slave should be able to take
> over from the master in case that one fails. In that case, the slave
> must suddenly become writable and your access controlling is void.
>
> In case you are preventing that, you are using replication only to
> transfer data and not to increase availability. That's fine, but it's
> quite a different use case. And something I admittedly haven't thought
> about. Thanks for pointing me to this use case of replication.

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).

> Hm.. yeah, that might be true. On the other hand, the servers in the
> cluster need to keep track of their state anyway, so there's not that
> much to be gained here.

In the case of a slave replicated node which is there to replace the master
when it goes offline, yes the slave needs to know it's a slave. PITR based
solution achieve this by having the slave eternaly in recovery mode, by the
time it pass this step it's a master.
Slony, AFAIUI, will soon be using the session_replication_role GUC to decide
about its "state". Here it's more interresting since a single server can acts
as a master for some data and as a slave for some others, and the triggers to
run are not the same depending on the role.

Of course, with multi-master replication, the client can INSERT to any member
of the cluster and the same triggers will get run, you're not after disabling
replication trigger if you're acting as a slave. 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 ;)
--
dim