Le mardi 05 août 2008, Markus Wanner a écrit : > I've thought about that as well, but think about it this way: to protect > against N failing nodes, you need to forward *every* request through N > living nodes, before actually hitting the node which processes the > query. To me, that sounds like an awful lot of traffic within the > cluster, which can easily be avoided with automatic client failover. > > (Why are you stating, that only slaves need to redirect? What is > happening in case of a master failure?)
I'm thinking in term of single master multiple slaves scenario... In single master case, each slave only needs to know who the current master is and if itself can process read-only queries (locally) or not. You seem to be thinking in term of multi-master, where the choosing of a master node is a different concern, as a failing master does not imply slave promotion. > > So the proposal for Automatic Client Failover becomes much more simpler. > > I'm arguing it's the other way around: taking down a node of the cluster > becomes much simpler with ACF, because clients automatically reconnect > to another node themselves. The servers don't need to care. Well, in the single master case I'm not sure to agree, but in the case of multi master configuration, it well seems that choosing some alive master is a client task. Now what about multi-master multi-slave case? Does such a configuration have sense? It this ever becomes possible (2 active/active masters servers, with some slaves for long running queries, e.g.), then you may want the ACF-enabled connection routine to choose to connect to any master or slave in the pool, and have the slave be itself an AFC client to target some alive master. Does this still makes sense? -- dim
signature.asc
Description: This is a digitally signed message part.
