Details
-
Bug
-
Status: In Testing (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.5, 10.6, 10.11, 11.1(EOL), 11.2(EOL), 11.4
-
None
Description
In the MDEV-32020 description, it's not repeated in detail here, two transaction cannot be isolated on slave because they used different non-unique indexes on master and slave.
As the first of the two is a prepared XA
--connection slave_worker_1
|
xa start 'xid'; /* ... lock here ... */ ; xa prepare 'xid' |
the 2nd
--connection slave_worker_2
|
begin; /* ... get lock ... => wait/hang...error out */ |
could not wait up for the conflicting lock, despite the XA transaction did not really
lock its target record of the non-clustered index.
The hang was really caused by a method to reach the needed record which is the index scan.
The scanning orthodoxically could not step over a record that was rightfully locked by the XA.
However as the record can not be targeted by the 2nd transaction, otherwise the transactions
would have sensed the conflict back on master, it would be alright to not panic
at seeing a timeout error from the engine. Instead the scanning would just proceed to next free index records of the same key value and ultimately must reach the target one.
More generally, on the way to its target all busy records belonging to earlier (binlog order) transactions need not to be locked by the current one.
A patch is implemented to carry out the description's agenda.
Attachments
Issue Links
- relates to
-
MDEV-32020 XA transaction replicates incorrectly, must be applied at XA COMMIT, not XA PREPARE
- Open