NAME
DBIO::Replicated - Replicated storage support for DBIO
VERSION
version 0.900004
SYNOPSIS
package MyApp::Schema;
use DBIO 'Schema', -pg;
__PACKAGE__->load_components('Replicated');
my $schema = __PACKAGE__->connect($dsn, $user, $pass, {
balancer_type => 'DBIO::Replicated::Balancer::First',
});
$schema->storage->connect_replicants(
[ $replica_dsn_1, $user, $pass ],
[ $replica_dsn_2, $user, $pass ],
);
See t/test/08_replicated.t for a runnable example.
DESCRIPTION
DBIO::Replicated is the DBIO core component for replicated storage setups. It configures the schema to use DBIO::Replicated::Storage, which then coordinates a master backend plus optional replicant backends.
Writes, transactions, deploy operations, and other master-only work go through the master backend. Read-oriented operations are delegated to the configured balancer, which selects from the active replicants.
For shared test suites, DBIO::Test can wrap a requested backend storage in replicated mode with:
my $schema = DBIO::Test->init_schema(
replicated => 1,
storage_type => 'DBIO::MySQL::Storage',
);
METHODS
connection
Overrides "connection" in DBIO::Schema to force +DBIO::Replicated::Storage as storage_type.
Replication runs on the driver the schema declares (ADR 0067): the master and every replicant are storages of that driver. connection reads the declared driver's storage class before it sets the replicated one and passes it on as backend_storage_class ("new" in DBIO::Replicated::Storage); a repeated connect keeps it. A backend_storage_class in the connect info wins over it. A schema that declares no driver, and gives no backend_storage_class, is refused before any storage is built.
The component is loaded after the driver component, so that the driver is declared when it connects and DBIO::Replicated::Storage is the storage class the schema ends up with:
__PACKAGE__->load_components(qw(PostgreSQL Replicated));
A schema whose connect leaves another storage class behind throws, naming that class and this order.
READING FROM THE MASTER AND THE REPLICANTS
A replicant answers with the data it has replicated so far; after a write on the master it may still show the earlier state for a short time (replication lag). Reads that tolerate this are balanced over the replicants.
Reads that go with a write are answered by the master, so they see what the writers see:
every select inside a transaction on the master
"find_or_create" in DBIO::ResultSet, "find_or_new" in DBIO::ResultSet, "update_or_create" in DBIO::ResultSet, "update_or_new" in DBIO::ResultSet and the
update_or_createfallback of "upsert" in DBIO::ResultSet: the lookup carriesforce_pool => 'master', supplied by the storage hook_read_pool_for_read_modify_write(ADR 0076)every select with a lock,
for => 'update',for => 'shared'or any other definedfor
A force_pool in the attributes of a search names the pool for that one read ('master' or the name of a replicant). To run a whole block of reads on the master, wrap it in "execute_reliably" in DBIO::Replicated::Storage:
$schema->storage->execute_reliably(sub {
my $artist = $schema->resultset('Artist')->find($id);
...
});
AUTHOR
DBIO & DBIx::Class Authors
COPYRIGHT AND LICENSE
Copyright (C) 2026 DBIO Authors Portions Copyright (C) 2005-2025 DBIx::Class Authors Based on DBIx::Class, heavily modified.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.