maria-developers team mailing list archive
Mailing list archive
Re: 答复: 答复: 答复: MDEV-520: consider parallel replication patch from taobao patches
>>>>> "Kristian" == Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:
Kristian> Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:
>> The patch makes later transactions wait for earlier transactions to commit
>> before committing themselves.
Kristian> Hm, I now realise a problem with this approach :-/
Kristian> The problem is with MyISAM tables, or other tables that use table-level
Kristian> locking instead of row-level locking.
Kristian> If transactions T1 and T2 both update the same table mytable, then it can
Kristian> happen that T2 runs first and gets a table lock on table mytable. T1 then has
Kristian> to wait for T2 to commit, after which the table lock is released. But T2 will
Kristian> never commit, it will wait for T1 to commit first with my patch. Thus we have
Kristian> a deadlock.
The simplest way to solve things like this is that for transactions that
are using table handlers with table level locking, you start the
transactions also in order; As soon as the table locks are taken
(after open_-and-lock-tables) you can start the next transaction.
Kristian> One way to fix this could be to extend your algorithm for detecting conflicts
Kristian> between different transactions. If some table T uses table-level locking, then
Kristian> put into the hash just the table name, without any primary key values. Then
Kristian> any two such transactions will be considered conflicting, and we avoid the
Kristian> deadlock. No loss of parallelism should occur, as two updates to the same
Kristian> MyISAM table can anyway not run in parallel.
Note that for Aria tables, multiple insert can be run at the same time.