- PXC#497: Warning: "BF applier failed to open_and_lock_tables"
Issue:
-----
Let me explain it with an example. Would be simpler.
Let's assume there are 2 pxc nodes and each node and following
workload is being
node-1: executes already prepare stmt and about to commit
(update i > 2 and i < 5)
node-2: executes some stmt that would conflict with node-1 (insert (3))
inserting in gap.
As per the protocol local trx is selected for rollback and so
when node-1 get node-2 trx which is applier trx node-1 local trx that
is prepare stmt execution is rolled back and re-tried using replay trx.
Note: retried using replay trx effectively means only write-set
is applied this makes it bit faster.
Application of write-set uses the apply-log-event path which
open and locks table so there is no need to keep track of
table versioning change which is normally done (in normal path)
by installing a reprepare observer.
Solution:
---------
* Avoid installing observer when prepare trx is being replayed
as trx will open and lock the tables.
commit d4fa27b020df425 a6421ae12a18de9 306cf5c90d
Merge: 9d30f12 f06d17f
Author: Krunal Bauskar <email address hidden>
Date: Thu Feb 18 06:35:17 2016 +0530
Merge pull request #90 from kbauskar/ 5.6-pxc- 497
- PXC#497: Warning: "BF applier failed to open_and_ lock_tables"
commit f06d17fd75c2aee 6dbdbecd81e0795 be1017284a
Author: Krunal Bauskar <email address hidden>
Date: Mon Feb 15 22:15:47 2016 +0530
- PXC#497: Warning: "BF applier failed to open_and_ lock_tables"
Issue:
-----
Let me explain it with an example. Would be simpler.
Let's assume there are 2 pxc nodes and each node and following
workload is being
node-1: executes already prepare stmt and about to commit
(update i > 2 and i < 5)
node-2: executes some stmt that would conflict with node-1 (insert (3))
inserting in gap.
As per the protocol local trx is selected for rollback and so
when node-1 get node-2 trx which is applier trx node-1 local trx that
is prepare stmt execution is rolled back and re-tried using replay trx.
Note: retried using replay trx effectively means only write-set
is applied this makes it bit faster.
Application of write-set uses the apply-log-event path which
open and locks table so there is no need to keep track of
table versioning change which is normally done (in normal path)
by installing a reprepare observer.
Solution:
---------
* Avoid installing observer when prepare trx is being replayed
as trx will open and lock the tables.