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 think that one could put the functionality that I implemented within DBD::Multiplex, but I'll need to sleep on 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. 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. - 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. 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. Henri
