maximum_lag ($num)¶

This is a number which defines the maximum allowed lag returned by the "lag_behind_master" in DBIx::Class::Storage::DBI method. The default is 0. In general, this should return a larger number when the replicant is lagging behind its master, however the implementation of this is database specific, so don't count on this number having a fixed meaning. For example, MySQL will return a number of seconds that the replicating database is lagging.

last_validated¶

This is an integer representing a time since the last time the replicants were validated. It's nothing fancy, just an integer provided via the perl time built-in.

replicant_type ($classname)¶

Base class used to instantiate replicants that are in the pool. Unless you need to subclass DBIx::Class::Storage::DBI::Replicated::Replicant you should just leave this alone.

replicants¶

A hashref of replicant, with the key being the dsn and the value returning the actual replicant storage. For example, if the $dsn element is something like:

  "dbi:SQLite:dbname=dbfile"

You could access the specific replicant via:

  $schema->storage->replicants->{'dbname=dbfile'}

This attributes also supports the following helper methods:

set_replicant($key=>$storage)

Pushes a replicant onto the HashRef under $key

get_replicant($key)

Retrieves the named replicant

has_replicants

Returns true if the Pool defines replicants.

num_replicants

The number of replicants in the pool

delete_replicant ($key)

Removes the replicant under $key from the pool

master¶

Reference to the master Storage.

connect_replicants ($schema, Array[$connect_info])¶

Given an array of $dsn or connect_info structures suitable for connected to a database, create an DBIx::Class::Storage::DBI::Replicated::Replicant object and store it in the "replicants" attribute.

connect_replicant ($schema, $connect_info)¶

Given a schema object and a hashref of $connect_info, connect the replicant and return it.

_safely_ensure_connected ($replicant)¶

The standard ensure_connected method with throw an exception should it fail to connect. For the master database this is desirable, but since replicants are allowed to fail, this behavior is not desirable. This method wraps the call to ensure_connected in an eval in order to catch any generated errors. That way a slave can go completely offline (e.g. the box itself can die) without bringing down your entire pool of databases.

_safely ($replicant, $name, $code)¶

Execute $code for operation $name catching any exceptions and printing an error message to the "<$replicant-"debugobj>>.

Returns 1 on success and undef on failure.

connected_replicants¶

Returns true if there are connected replicants. Actually is overloaded to return the number of replicants. So you can do stuff like:

  if( my $num_connected = $storage->has_connected_replicants ) {
    print "I have $num_connected connected replicants";
  } else {
    print "Sorry, no replicants.";
  }

This method will actually test that each replicant in the "replicants" hashref is actually connected, try not to hit this 10 times a second.

active_replicants¶

This is an array of replicants that are considered to be active in the pool. This does not check to see if they are connected, but if they are not, DBIC should automatically reconnect them for us when we hit them with a query.

all_replicants¶

Just a simple array of all the replicant storages. No particular order to the array is given, nor should any meaning be derived.

validate_replicants¶

This does a check to see if 1) each replicate is connected (or reconnectable), 2) that is ->is_replicating, and 3) that it is not exceeding the lag amount defined by "maximum_lag". Replicants that fail any of these tests are set to inactive, and thus removed from the replication pool.

This tests "all_replicants", since a replicant that has been previous marked as inactive can be reactivated should it start to pass the validation tests again.

See DBIx::Class::Storage::DBI for more about checking if a replicating connection is not following a master or is lagging.

Calling this method will generate queries on the replicant databases so it is not recommended that you run them very often.

This method requires that your underlying storage engine supports some sort of native replication mechanism. Currently only MySQL native replication is supported. Your patches to make other replication types work are welcomed.