DOTS test BTCJ4 can result in inconsistency
Bug #373554 reported by
Seppo Jaakola
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL patches by Codership |
Fix Released
|
Medium
|
Seppo Jaakola |
Bug Description
Running DOTS test BTCJ4 can sometimes leave cluster nodes in inconsistent state.
Looking in the data shows, that some UPDATES/INSERTS were applied only in the
master/delegate node.
Changed in codership-mysql: | |
assignee: | nobody → Seppo Jaakola (seppo-jaakola) |
importance: | Undecided → Medium |
milestone: | none → 0.6 |
status: | New → In Progress |
Changed in codership-mysql: | |
status: | In Progress → Fix Committed |
Changed in codership-mysql: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Drilling down shows that this can happen if following conditions are met:
* RBR replication level
* binlog files disabled (lob_bin option not set)
* autocommit mode transactions
Then, in the node under inspection, it happens that a (local state) query gets aborted by BF.
This aborting happens correctly, in the sense that the BF transaction gets the locks needed
and is able to complete. However, the connection for the aborted query starts a new query
(with different SQL) and replicating this latter query does not happen correctly.
The latter query gets committed in the node under inspection, but is not applied in any other
node in the cluster. I can verify, that the write set is delivered in each node and certitification
is good for every node.
=> assumption is that transaction cache is not initialized correctly in the aborting phase.