This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello, I was wondering if there is, or can be, support for sending Writes to one connection string and Reads to another, in a replication scenario. Ideally by supplying two connection strings with MODE parameter. <add name="Development" connectionString="server=master-db;User Id=development;password=;Persist Security Info=True;database=test" mode="Write"/> <add name="Development" connectionString="server=slave1-db;User Id=development;password=;Persist Security Info=True;database=test" mode="Read"/>
INSERT, UPDATE, DELETE ---- WRITE = master Alternatively is there anyway to easily do this programatically?
And on a similar vein - though not sure logistically if it's feasible - Could you specify a pool of slave nodes that you roundrobin, or randomly select - thus a primitive load balancer? Many Thanks, Scott
|
|
|
No, we don't have anything like this. Not sure about programmatic approaches -- you could maybe use a custom connection strategy, and override UnitOfWork.SaveChanges(bool) to instruct the connection strategy to disconnect from the slave database and connect to the master database, then on completion switch back again. Bit kludgy though... There's no built-in support for pools of nodes, but you could build one reasonably easily by creating a collection of LightSpeedContexts with different connection strings, and whenever you need to create a UOW you would choose on randomly or according to an algorithm. Each UOW would have to be connected to the same node for its duration, but different UOWs could end up on different nodes, giving you load balancing at the UOW level though not at the query level. All that said, if your database platform provides built-in replication and clustering, it's probably worth investigating that rather than trying to build it yourself. I can envision all sorts of issues around transactionality, reliability and concurrency with this kind of thing, and in the long run it's likely to prove easier to use somebody else's proven solution rather than trying to build your own. Depends on availability and cost of course! |
|
|
Thanks Ivan for the reply.
I agree with your analysis that the programmatic approach using a connection strategy would be clunky. If there is no way to support writes to the Master and reads from the slave at lightspeed level, its a shame but I am thinking the performance decrease isn't so signifigant to give up on the tool. Lightspeed is fantastic, hands down - can't recommend it enough. The pools idea was just off the back of the other idea, not really important but I see how your solution of randomising the connection string would work.
Cheers, Scott |
|