On Fri, Oct 11, 2002 at 05:01:39PM -0700, Henri Asseily wrote: > > On Friday, October 11, 2002, at 02:39 PM, Tim Bunce wrote: > >> > >>There hasn't been up to now (or at least I haven't found any) a widely > >>available Perl/DBI-based system for system architects who handle > >>high-availability groups of servers, either in read-only load-balanced > >>mode or read-write hot-backup mode. > > > >Have you looked at DBD::Multiplex? > > > >I'd be interested in your thoughts on DBD::Multiplex, both specifically > >and the underlying concept of using a 'virtual driver' to encapsulate > >the functionality. > > Wow, DBD::Multiplex is a nice piece of code. The concept of a virtual > driver is great.
I'm glad you like it. > Basically I think Multiplex would need the following: > 1- better implementation of timeouts, both at the connect and at the > execute level > 2- better support for high-performance environments and mod_perl, > mostly by having a "memory state" > > Regarding (1), Multiplex still relies upon the base driver's timeout > system, which can hardly be relied upon. That's a pretty easy fix. Yeap. Though any timeout based on signals may leave the connection in an unsafe state. (But that's a generic issue.) > For (2), here are a number of use cases where Multiplex is less than > optimal: > > - I send a badly formed SQL statement. Multiplex will automatically go > through all dsns and execute that statement, hoping against all hope > that one server will manage to execute it. My proposal is to wipe the > connection, reconnect (with success) to the original dsn and reexecute > only once. If that fails, forget it and pass that back to the client. How can you (portably) differenciate between "badly formed SQL statement" and something like a duplicate key on insert? An application may be using insert-then-update-if-insert-fails logic. Reconnecting on each failed insert would work but perform very badly. I'd like to see Multiplex provide general *mechanisums* that enable applications to define their own *policy*. Without that Multiplex (or HA) won't be able to suit most applications all the time. > - My master DB server dies, in a master-slave configuration that uses a > replication engine. Multiplex will always try the master server first, > with no memory of its state. That's bad in any configuration, including > Apache::DBI. In Apache::DBI, the cached handle is dead and will never > recover unless it's wiped. (in fact, in any case using Apache::DBI will > be a problem due to the caching of bad dbh's even if the server > recovered). In non-Apache::DBI, if you make the mistake of bringing the > master back up for testing, Multiplex will start hitting it before the > master has time to do a reverse-replication. Your replication system is > then shot. Basically, when you fail over automatically, you want to > remain failed over until the DBA flips the switch back manually. Yeap. (Same comment as above though.) > Anyway, I'm going to dig deeper into all this and potentially make my > configuration structures compatible with DBD::Multiplex, which would > then allow for seamless use of it. By then the logic flows will > necessitate a supercomputer to debug... :) > Or of course I could take DBD::Multiplex and extend it with the logic > that I built. I'll let the list know my findings. I will probably > release the HA module first (with or without the MM functionality) and > then get some feedback going. As you can tell from my comments above, I'd really like to find a way to separate mechanism and policy and provide an API that DBD::Multiplex can offer to applications to express/implement the required policy. It could be that DBIx::HA ends up providing some pre-canned policies that "plug in" to DBD::Multiplex via the API. Tim.
