The main thrust of my HA module is failover, not load balancing (even though it works that way as well).
It is also optimized for an Apache::DBI configuration, where shared files can be used for inter-process communication (if one handle fails x number of times in one process, it can automatically fail over the other processes).
It is a seamless replacement to Apache::DBI and I've had it running in heavy production for a while. If anyone's interested I'll post it to CPAN.
The only "problem" is that it uses higher-level DBI calls to do its magic, rather than lower-level DBD calls. It's a different strategy than DBD::Multiplex, but gave me a much faster development schedule.
There's a connect timeout, execute timeout, failover level (process or application level), etc...
Also the idea is that if a database server is considered failed, it will never be re-tried unless the system is manually reset. This is critical in case the failed server is restarted and being tested.
H
On Monday, June 23, 2003, at 11:05 AM, Tim Bunce wrote:
On Sat, Jun 21, 2003 at 08:49:28PM +0100, Adam Gent wrote:Hi,
Is there any news on this update to DBD::Multiplex?
On one hand my work priorities have shifted so I've less time to work on it.
On the other, I spotted Alex Rak [CC'd] post DBIx::DBCluster module to CPAN:
http://search.cpan.org/author/ARAK/DBIx-DBCluster-0.01/DBCluster.pm
and I've won him over to the DBD::Multiplex approach.
He's now working on a patch to my development version to incorporate some good ideas of his own (and hopefully implement some more of the ones liste below :-)
Any news Alex?
Tim.
Thanks,
Adam
----- Original Message ----- From: "Tim Bunce" <[EMAIL PROTECTED]> To: "Thomas Kishel" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 13, 2003 11:23 PM Subject: DBD::Multiplex
On Tue, May 13, 2003 at 02:03:28PM -0400, Thomas Kishel wrote:Tim,
So far, the most recent version works well on my systems here.
An update for those on [EMAIL PROTECTED] (and for the people I've Bcc'd who have emailed Thomas about DBD::Multiplex in the past)...
I've been working on DBD::Multiplex recently and have added some significant functionality as well as made it a far more compatible (standard) DBD and more 'transparent' so applications are less aware of DBD::Multiplex 'getting in the way' between themselves and the underlying driver(s).
I am still interested in your opinion of using SQL::Parser for statement parsing. Appropriate? Efficient? Or not?
Efficiency is a concern, but I have a cunning plan...
I'm thinking of removing mx_exit_mode and replacing it with some new attributes that will offer much greater flexibility...
Something along these lines:
mx_pick_handles = sub { ... }
The mx_pick_handles sub decides which child handles will be used.
The default mx_pick_handles sub will implement the mx_master_id logic, but the application can supply it's own code to use whatever logic it wants to pick the ordered set of handles to use. For example: multiple masters, smarter load balancing, routing queries depending on which tables are mentioned etc etc.
The mx_pick_handles sub can also set the values of these attributes differently for each call:
mx_reconnect = true | false | skip_disconnected
If true, then when calling a dbh method the dbh's returned by
mx_pick_results are ping()'d and reconnect()'d if possible before use.
The skip_disconnected value implies true and if the reconnect fails
then the handle is removed from the list to be used (so it won't
generate an error). Though it is an error for no handles to be left.
mx_shuffle = true | false
If true, shuffles randomly the set of handles returned by mx_pick_handles.
mx_errors = first | last | ignore
First means stop and abort with the first error. Last means run all
child handles but then abort with the last error encountered.
Ignore means ignore any errors unless ALL child handles generate errors.
mx_results = first | last | union
First means stop after the first success. Last means return the last but implies that all results are remembered for later (see mx_pick_results below). Union is a special case I'll discuss below.
mx_pick_results = sub { ... }
The mx_pick_results sub decides how to interpret the results.
The default mx_pick_results sub will implement the 'post-loop' semantics implied by the mx_errors and mx_results attributes above.
mx_as_select = true | false
The mx_as_select attribute turns non-select statements into select statement that return five fields: mx_id err errstr info, with one row per child handle. This is implemented already and is especially useful with the DBI::Shell.
The mx_results = union mode mentioned above is similar but applies to select statements. The results of a select with mx_results = union is the union of all the rows returned by all the child handles. This is also implemented already.
A final piece of magic is the ability to embed into the SQL statement escape sequences that get expanded differently for each child handle. This is especially useful with mx_results = union. For example,
select '{mx id}' id, foo, bar from table where foo > bar or select * from table where id = '{mx id}' or drop table foo_{mx id}
It's also possible to set handle attributes via embedded escape clauses:
{dbi mx_as_select=1} delete from foo
This's also implemented already, though I'm not set on the escape clause syntax.
Comments?
Tim.
p.s. For those not on the dbi-dev mailing list who I've Bcc'd this
to, let me know if you want to be included in any ongoing discussions.
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003
