[Catalyst] Re: Catalyst::TraitFor::Model::DBIC::Schema::Replicated connect info

[Rafael Kitover]

On Mon, Jun 07, 2010 at 05:39:25PM -0700, Bill Moseley wrote:
> On Mon, Jun 7, 2010 at 12:58 PM, Rafael Kitover <rkitover at cpan.org> wrote:
> 
> > The ::DBI::Replicated storage, to my knowledge, has only been tested on
> > MySQL. If you are using it successfully with Postgres I would love to
> > hear the details. Which replication software you are using, and does it
> > work as you expect.
> >
> 
> I've just started looking into using Replicated.
> 
> Slony is used for replication and there's discussion of using pgbouncer for
> slave connection pooling.  An existing application that uses the same
> database has a DBI subclass that works at the $dbh level to provide
> replication, so looking at using that also.
> 
> Memcached is track when to force reads to the master after a write.  This is
> keyed by user id -- i.e. once a user does a write then they are forced to
> the master for an amount of time to let the slaves catch up.
> 
> What I'm now wondering about is where I could hook in to determine when a
> write to the master happens so I can make all subsequent queries also go to
> the master and to set a flag in memcached for other processes to detect.
> 
> But, this is a discussion that should be on the DBIC list.
> 
> -- 
> Bill Moseley
> moseley at hank.org

To detect a write, it is probably enough to 'around' insert, update,
insert_bulk and delete (::DBI::Replicated is Moose.) They are handled by
the master storage delegate.

Two methods you might want to implement in your delegated-to storages
are is_replicating and lag_behind_master (see ::Storage::DBI and
::DBI::Replicated::Pool .)

With the default implementation, you of course are not guaranteed to
always have the latest data when reading from a slave.