Rob Wultsch wrote: > 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.
It is necessary, but not sufficient. Two transactions that are serialized in a particular order on the master can end up with a deadlock if they progress at different speeds. For engines that uses row-based locking, it might be that the locking order of the rows are different on the master and the slave, leading to deadlock and can end with the "wrong" transaction being rolled back because the slave makes a different decision on what transaction to roll back than the master did. Just my few cents, Mats Kindahl > -- Mats Kindahl Senior Software Engineer Database Technology Group Sun Microsystems _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
