← Back to team overview

maria-developers team mailing list archive

Re: 答复: 答复: 答复: MDEV-520: consider parallel replication patch from taobao patches


On Thu, 10 Jan 2013 14:24:32 +0100, Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> wrote:
Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:

The patch makes later transactions wait for earlier transactions to commit
before committing themselves.

Hm, I now realise a problem with this approach :-/

The problem is with MyISAM tables, or other tables that use table-level
locking instead of row-level locking.

If transactions T1 and T2 both update the same table mytable, then it can happen that T2 runs first and gets a table lock on table mytable. T1 then has to wait for T2 to commit, after which the table lock is released. But T2 will never commit, it will wait for T1 to commit first with my patch. Thus we have
a deadlock.

One way to fix this could be to extend your algorithm for detecting conflicts
between different transactions. If some table T uses table-level
locking, then
put into the hash just the table name, without any primary key values. Then any two such transactions will be considered conflicting, and we avoid the deadlock. No loss of parallelism should occur, as two updates to the same
MyISAM table can anyway not run in parallel.

But multiple inserts can occur in parallel if rows are fixed-length. This
is an important feature for a particular purpose I use daily
(event logging getting replicated from data collectors to data aggregators).

Having a way to get past the single-thread bottleneck on a pure-insert
workload would be extremely useful. I have to use a non-transactional
table engine for the replicated table because of a quirk with data commits straddling replication stopping/starting and table renaming/re-creation.


Follow ups