NAME

SYNOPSIS

You should set the 'storage_type attribute to a replicated type. You should also define your arguments, such as which balancer you want and any arguments that the Pool object should get.

  my $schema = Schema::Class->clone;
  $schema->storage_type(['::DBI::Replicated', { balancer_type => '::Random' }]);
  $schema->connection(...);

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.

  $schema->storage->connect_replicants(
    [$dsn1, $user, $pass, \%opts],
    [$dsn2, $user, $pass, \%opts],
    [$dsn3, $user, $pass, \%opts],
  );

Now, just use the $schema as you normally would. Automatically all reads will be delegated to the replicants, while writes to the master.

  $schema->resultset('Source')->search({name=>'etc'});

You can force a given query to use a particular storage using the search attribute 'force_pool'. For example:

  my $rs = $schema->resultset('Source')->search(undef, {force_pool=>'master'});

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:

  my $rs = $schema->resultset('Source')->search( undef,
    { force_pool => $db->storage->read_handler->next_storage }
  );

DESCRIPTION

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.

Basically, any method request that DBIx::Class::Storage::DBI would normally handle gets delegated to one of the two attributes: "read_handler" or to "write_handler". Additionally, some methods need to be distributed to all existing storages. This way our storage class is a drop in replacement for DBIx::Class::Storage::DBI.

Read traffic is spread across the replicants (slaves) occurring to a user selected algorithm. The default algorithm is random weighted.

NOTES

REQUIREMENTS

ATTRIBUTES

ATTRIBUTES IMPLEMENTING THE DBIx::Storage::DBI INTERFACE

METHODS

  my $reliably = sub {
    my $name = shift @_;
    $schema->resultset('User')->create({name=>$name});
    my $user_rs = $schema->resultset('User')->find({name=>$name});
    return $user_rs;
  };

  my $user_rs = $schema->storage->execute_reliably($reliably, 'John');

GOTCHAS

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:

  my $result = $resultset->search(undef, {force_pool=>'master'})->find($pk);

This attribute will safely be ignored 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.

FURTHER QUESTIONS?

COPYRIGHT AND LICENSE