Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.5.34-galera
-
Fix Version/s: 5.5.35-galera
-
Component/s: None
-
Labels:None
Description
Same test as in #5604.
The UPDATE doesn't update anything, but a deadlock is throw on the COMMIT.
[2014-02-03 10:47:24] 12: [WARNING] Updated didn't matched the inserted! Inserted: 5, Updated: 0
[2014-02-03 10:47:24] 12: [ERROR 1] UPDATE 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
This is great! But wsrep_local_bf_aborts status value doesn't increase.
From the error log:
140202 19:49:23 [Note] WSREP: BF kill (1, seqno: 3311463), victim: (132) trx: 3633573 140202 19:49:23 [Note] WSREP: Aborting query: void 140202 19:49:23 [Note] WSREP: kill IDLE for 3633573 140202 19:49:23 [Note] WSREP: enqueuing trx abort for (132) 140202 19:49:23 [Note] WSREP: signaling aborter 140202 19:49:23 [Note] WSREP: WSREP rollback thread wakes for signal 140202 19:49:23 [Note] WSREP: client rollback due to BF abort for (132), query: (null) 140202 19:49:23 [Note] WSREP: WSREP rollbacker aborted thd: (132 140630848161536) 140202 19:49:23 [Note] WSREP: Deadlock error for: (null)
The timestamp mismatch is between my local computer and my node, sorry.
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Hi Jan,
I was able to get 5.5.35-galera as well as Galera 25.2.8. It looks like a few things have changed, so I'm digesting the changes and will report as soon as possible.
Thanks,
-will
Hi,
If you still see that BF kill doesn't reflect in wsrep_local_bf_aborts, I will need full, unedited error log from both servers.
Thanks
Jan
Hi,
Provided information is quite limited. Could you provide actual output of status variable wsrep_local_bf_aborts from both servers, I have seen that this variable is increased on current version we are working (5.5.35-galera).