On Thu, May 7, 2009 at 10:08 PM, Rob Wultsch <[email protected]> wrote: > 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] >
Thinking about it more I wonder if forcing the transaction to commit on the slave in the order that they were committed on the master would be part of the solution. -- 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
