Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

support Replication #23

Closed
xenoterracide opened this Issue · 11 comments

2 participants

@xenoterracide

DBIC has some nice replication features that would be cool if they could be used in DBIx::Connector. That way it supports all of the connection features of DBIC. http://search.cpan.org/~ribasushi/DBIx-Class-0.08120/lib/DBIx/Class/Storage/DBI/Replicated.pm

@theory
Owner

Replication should never be done at the app layer. It should be done at the database layer. So I am philosophically opposed to such a thing.

That said, there's nothing to stop someone else from adding it in a subclass, or using DBD::Multiplex or something.

@theory theory closed this
@xenoterracide

how odd.. given that DBIx::Connector is at the database layer IMO not the App layer. But your module.

@theory
Owner

No, DBIx::Connector is at the app layer. Bucardo is something at the database layer: That is, inside the database.

@xenoterracide

oh if you're talking layers like that... but that's overall system architecture. What I'm talking about is more like PG Pool than Bucardo. I was thinking more within the Layers of the application. DBIx::Connector is at the db or service layer within an application. (also I think my brain is confusing "application layer" due to me having to explain layered architecture to local team. I use it to refer to the Mojo/Dancer/Catalyst app.). In any regard the feature is not to facilitate multimaster or the actual replication, but very simple pooling of servers so your database connection handle can have seperate read/write slaves that are easy to access. e.g. I can ask for read only's and it will select from a pool.

@theory
Owner

Oh, I wouldn't call that replication. Not sure what I would call it… At any rate, I expect it wouldn't be too hard to build something like that on top of DBIx::Connector.

@xenoterracide

I may have worded it wrong, which is why I linked to the feature in DBIC. Basically it's simplistic pooling for the replicants. It just seems like something that could be extracted and would be useful to extract from DBIC.

@theory
Owner

Maybe, but for pooling, I actually prefer something like pgBouncer. Most of that kind of giggery-pokery at the Perl app level (and by "level" I mean stuff written in Perl and running outside the database, not anything to do with MVC) to be unreliable and error-prone.

Switching between handles for reads and writes is pretty straight-forward, though: just have two database handles (or DBIx::Connector objects).

@xenoterracide

oh of course you're right, though something in DBIx::Connector native would ultimately be less error prone than things I've seen implemented. (oh god my boss wrote something that was using a single $self->{handle} and had like a set writer / set reader that modified that and on top of it I think this single object was passed everywhere, IIRC ). passing handles is of course possible, I'm just thinking that it'd be nice to flag transaction rw or ro, and have it select from the pool, if the pool is 1 server then you get the same handle. It comes down to the problem of where is the best place to put the "get the right handle" logic. Specifically for 'ease of adding servers' later (I only use one now).

@theory
Owner

I dunno, that feels higher level than DBIx::Connector, but maybe not? Not at all sure, would need to actually work with a system like that to get a feel for the right level of handle selection.

On the other hand, I would might try to use PGPool II and let it figure out what to do with each query.

@xenoterracide

unfortunately we don't use Pg, so... and our ... CTO? is a changophobe which means he wouldn't want to introduce that layer (no that doesn't make sense)

@theory
Owner

I would not be surprised if there was something similar for your DB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.