On Thu, May 7, 2009 at 8:10 PM, Baron Schwartz <[email protected]> wrote: > Clint's proposal would work very well for certain workloads. At a > coarser level, it would be beneficial for some other workloads to do > table-level dependency checking. This is a very old and well > understood problem as far as I know (though I am not the expert on it > myself) -- I remember studying this in chip architecture classes in > college. > > That is: if two transactions don't touch the same tables, they are > fine to run concurrently, in any order. Or even if they do -- as long > as they're only reading from the shared tables, they're fine to run > concurrently. It's all a question of read-after-write and write-after > write and all that -- there are only four combinations. > > There are a lot of edge cases that I think would make this > complicated. If the slave stops while it was applying several > transactions, where should it start again? Maybe transaction 5 was > finished, but 4 and 3 were halfway through and got rolled back. I > expect a lot of similar nasties to rear their heads. > > (This particular one could be solved by executing parallel but > commiting in the original order, of course.) > > Baron >
Disclaimer: I am sure I do not understand the scope of the problem well enough to intelligently comment. I will be interested to hear what is wrong with what I outline below. Perhaps a log of what transactions have committed would be useful. Assuming we are considering transactional storage engines then the uncommitted transactions should rollback if replication is stopped or the server dies unexpectedly. When replication restarts replication would start executing the oldest transaction, and move forward in the log ignoring any transaction that have already committed. I think that non-transactional engines might also be able to use such a technique if one treats every query as a standalone transaction. Partially completed queries on non-transaction engines are problematic though. In terms of the issue of deadlocks would a possible solution be record the start and end time (actually time is rather horrible, perhaps a some sequence of some sort) of each transaction on the master and have earlier transaction block newer transaction if there is the possibility that the same resource might be being altered. Perhaps if there is a deadlock have the newer transaction rollback and wait to execute until the older transaction has completed? Assuming older transactions or pseudo transaction block newer ones I think this would work with non-transactional engines. -- Rob Wultsch [email protected] _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
