On Mon, Jun 07, 2010 at 05:39:25PM -0700, Bill Moseley wrote: > On Mon, Jun 7, 2010 at 12:58 PM, Rafael Kitover <rkito...@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 > mose...@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. _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
