Next, you need to add in the Replicants. Basically this is an array of arrayrefs, where each arrayref is database connect information. Think of these arguments as what you'd pass to the 'normal' $schema->connect method.

Now $rs will force everything (both reads and writes) to use whatever was setup as the master storage. 'master' is hardcoded to always point to the Master, but you can also use any Replicant name. Please see: DBIx::Class::Storage::DBI::Replicated::Pool and the replicants attribute for more.

Also see transactions and "execute_reliably" for alternative ways to force read traffic to the master. In general, you should wrap your statements in a transaction when you are reading and writing to the same tables at the same time, since your replicants will often lag a bit behind the master.

If you have a multi-statement read only transaction you can force it to select a random server in the pool by:

Warning: This class is marked BETA. This has been running a production website using MySQL native replication as its backend and we have some decent test coverage but the code hasn't yet been stressed by a variety of databases. Individual DBs may have quirks we are not aware of. Please use this in first development and pass along your experiences/bug fixes.

This class implements replicated data store for DBI. Currently you can define one master and numerous slave database connections. All write-type queries (INSERT, UPDATE, DELETE and even LAST_INSERT_ID) are routed to master database, all read-type queries (SELECTs) go to the slave database.

The consistency between master and replicants is database specific. The Pool gives you a method to validate its replicants, removing and replacing them when they fail/pass predefined criteria. Please make careful use of the ways to force a query to run against Master when needed.

The master defines the canonical state for a pool of connected databases. All the replicants are expected to match this databases state. Thus, in a classic Master / Slaves distributed system, all the slaves are expected to replicate the Master's state as quick as possible. This is the only database in the pool of databases that is allowed to handle write traffic.

Defines an object that implements the write side of BIx::Class::Storage::DBI, as well as methods that don't write or read that can be called on only one storage, methods that return a $dbh, and any methods that don't make sense to run on a replicant.

All calls to connect_replicants needs to have an existing $schema tacked onto top of the args, since DBIx::Storage::DBI needs it, and any connect_info options merged with the master, with replicant opts having higher priority.

Due to the fact that replicants can lag behind a master, you must take care to make sure you use one of the methods to force read queries to a master should you need realtime data integrity. For example, if you insert a row, and then immediately re-read it from the database (say, by doing $result->discard_changes) or you insert a row and then immediately build a query that expects that row to be an item, you should force the master to handle reads. Otherwise, due to the lag, there is no certainty your data will be in the expected state.

For data integrity, all transactions automatically use the master storage for all read and write queries. Using a transaction is the preferred and recommended method to force the master to handle all read queries.

Otherwise, you can force a single query to use the master with the 'force_pool' attribute:

This attribute will safely be ignore by non replicated storages, so you can use the same code for both types of systems.

Lastly, you can use the "execute_reliably" method, which works very much like a transaction.

For debugging, you can turn replication on/off with the methods "set_reliable_storage" and "set_balanced_storage", however this operates at a global level and is not suitable if you have a shared Schema object being used by multiple processes, such as on a web application server. You can get around this limitation by using the Schema clone method.

my $new_schema = $schema->clone;
$new_schema->set_reliable_storage;
## $new_schema will use only the Master storage for all reads/writes while
## the $schema object will use replicated storage.