[gradebook2-dev] MySQL transactions

[Kusnetz, Jeremy]

We are working on a project to scale up our MySQL instance by
incorporating some read/write splitting to a master MySQL node and
multiple slave nodes.  The main theory is writes should go the master
and reads should go to the slaves (which are replicating from the
master).  If writes and reads are all incorporated within a transaction,
then all the writes AND reads from that transaction should all go to the
master.  This prevents problems dealing with replication latency.

 

Everything seems to be working well in Sakai, except for Gradebook2.

 

I haven't looked at the code yet, but the way it's acting is if certain
groups of queries aren't within transactions.

 

So for example if you remove an item, all the remaining items within the
category should automatically update their weights.  But when we have
r/w splitting enabled, this doesn't happen all of the time.  Sometimes
the item will go away, but the remaining items won't update their
weights.  Again without looking it looks like the update of the item to
set it as deleted is not in a transaction with updating the remaining
item's weight values.  If all of these were in a transaction then all
the updates and selects would hit the master node which would obviously
be in sync with itself.

 

Any thoughts?

 

Jeremy Kusnetz | Sr. Systems Engineer

 

American Public University System 
American Military University  |  American Public University
661 S George Street, Charles Town, WV 25414 
T 304-885-5333 | M 703-967-5212 |  jkusnetz at apus.edu
<mailto:jkusnetz at apus.edu> | www.apus.edu <http://www.apus.edu> 

 

This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/gradebook2-dev/attachments/20120202/12cc840a/attachment.html