The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.


DBD::Multiplex - A multiplexing driver for the DBI.


 use strict;

 use DBI;

 my ($dsn1, $dsn2, $dsn3, $dsn4, %attr);

 # Define four databases, in this case, four Postgres databases.
 $dsn1 = 'dbi:Pg:dbname=aaa;host=;mx_id=dbaaa1';
 $dsn2 = 'dbi:Pg:dbname=bbb;host=;mx_id=dbbbb2';
 $dsn3 = 'dbi:Pg:dbname=ccc;host=;mx_id=dbccc3';
 $dsn4 = 'dbi:Pg:dbname=ddd;host=;mx_id=dbddd4';

 # Define a callback error handler.
 sub MyErrorProcedure {
        my ($mx_id, $error_number, $error_string) = @_;
        my ($filepath, $extension) = ('/tmp/', '.txt');
        open (TFH, ">>$filepath$mx_id$extension");
        print (TFH "$error_number\t$error_string\n");
        close (TFH);
        return 1;

 # Define the pool of datasources.
 %attr = (
        'mx_dsns' => [$dsn1, $dsn2, $dsn3, $dsn4],
        'mx_master_id' => 'dbaaa1',
        'mx_connect_mode' => 'ignore_errors',
        'mx_exit_mode' => 'first_success',
        'mx_error_proc' => \&MyErrorProcedure,

 # Connect to all four datasources.
 $dbh = DBI->connect("dbi:Multiplex:", 'username', 'password', \%attr); 

 # See the DBI module documentation for full details.


DBD::Multiplex is a Perl module which works with the DBI allowing you to work with multiple datasources using a single DBI handle.

Basically, DBD::Multiplex database and statement handles are parents that contain multiple child handles, one for each datasource. Method calls on the parent handle trigger corresponding method calls on each of the children.

One use of this module is to mirror the contents of one datasource using a set of alternate datasources. For that scenario it can write to all datasources, but read from only from one datasource.

Alternatively, where a database already supports replication, DBD::Multiplex can be used to direct writes to the master and spread the selects across multiple slaves.


A goal of this module is to be compatible with DBD::Proxy / DBI::ProxyServer. Currently, the 'mx_error_proc' feature generates errors regarding the storage of CODE references within the Storable module used by RPC::PlClient which in turn is used by DBD::Proxy. Yet it works.


Multiple datasources are specified in the either the DSN parameter of the DBI->connect() function (separated by the '|' character), and/or in the 'mx_dsns' key/value pair (as an array reference) of the \%attr parameter.


Multiplex attributes are specified in the either the DSN parameter of the DBI->connect() function (separated from the DSNs by the '#' character), and/or in the the \%attr parameter. Attributes in the \%attr parameter will overwrite attributes from the DSN parameter.

The following specific attributes can be set when connecting:


An array reference of DSN strings.


Specifies which mx_id will be used as the master server for a master/slave one-way replication scheme.


Options available or under consideration:


A failed connection to any of the data sources will generate a DBI error. This is the default.


Failed connections are ignored, forgotten, and therefore, unused.


Options available or under consideration:


Execute the requested method against each child handle, stopping after the first error, and returning the all of the results. This is the default.


Execute the requested method against each child handle, stopping after the first successful result, and returning only the successful result. Most appropriate when reading from a set of mirrored datasources.


Randomly reorders the list of DSNs, and then connects to them in that order. Then switches to first_success mode. You can redefine mx_exit_mode after connecting.

         $dbh->{'mx_exit_mode'} = 'last_result';


Execute the requested method against each child handle, not stopping after any errors, and returning all of the results.


Execute the requested method against each child handle, not stopping after the errors, and returning the most common result (eg three-way-voting etc). Not yet implemented.


A reference to a subroutine which will be executed whenever a DBI method generates an error when working with a specific datasource. It will be passed the DSN and 'mx_id' of the datasource, and the $DBI::err and $DBI::errstr.

Define your own subrouine and pass a reference to it, or pass a reference to the default error_proc:


Remember that references to subroutines do not include the parentheses.

In some cases, the exit mode will depend on the method being called. For example, this module will always execute $dbh->disconnect() calls against each child handle.

In others, the default will be used, unless the user of the DBI specified the 'mx_exit_mode' when connecting, or later changed the 'mx_exit_mode' attribute of a database or statement handle.


Here's an example of using DBD::Multiplex with MySQL's replication scheme.

MySQL supports one-way replication, which means we run a server as the master server and others as slaves which catch up any changes made on the master. Any READ operations then may be distributed among them (master and slave(s)), whereas any WRITE operation must only be directed toward the master. Any changes happened on slave(s) will never get synchronized to other servers. More detailed instructions on how to arrange such setup can be found at:

Now say we have two servers, one at as a master, and one at as a slave. The DSN for each server may be written like this:

 my (@dsns) = qw{

Here we choose easy-to-remember mx_ids: masterdb and slavedb. You are free to choose alternative names, for example: mst and slv. Then we create the DSN for DBD::Multiplex by joining them, using the pipe character as separator:

 my ($dsn) = 'dbi:Multiplex:' . join('|', @dsns);
 my ($user) = 'username';
 my ($pass) = 'password';

As a more paranoid practice, configure the 'user's permissions to allow only SELECTs on the slaves.

Next, we define the attributes which will affect DBD::Multiplex behaviour:

 my (%attr) = (
        'mx_exit_mode' => 'first_success_random',
        'mx_master_id' => 'masterdb',

These attributes are required for MySQL replication support:

We set mx_exit_mode to 'first_success_random' which will make DBD::Multiplex shuffle the DSN list order prior to connect, and afterwards revert to 'first_success'.

The mx_master_id attribute specifies which mx_id will be recognized as the master. In our example, this is set to 'masterdb'. This attribute will ensure that every WRITE operation will be executed only on the master server. Finally, we call DBI->connect():

 $dbh = DBI->connect($dsn, $user, $pass, \%attr) or die $DBI::errstr;


Copyright (c) 1999,2000,2003, Tim Bunce & Thomas Kishel

While I defer to Tim Bunce regarding the majority of this module, feel free to contact me for more information:

        Thomas Kishel

You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file.