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
I have a script that inserts 10 records into a table on Node 1. Immediately after, I run an update on Node 2 on those inserted records. I run 100 of these transactions. The intention here is to test and monitor replication conflicts.
[2014-02-01 12:37:50] 50: [WARNING] Updated didn't matched the inserted! Inserted: 10, Updated: 9 [2014-02-01 12:37:50] 55: [WARNING] Updated didn't matched the inserted! Inserted: 10, Updated: 9 [2014-02-01 12:37:50] 78: [WARNING] Updated didn't matched the inserted! Inserted: 10, Updated: 9 [2014-02-01 12:37:50] 79: [WARNING] Updated didn't matched the inserted! Inserted: 10, Updated: 9 [2014-02-01 12:37:51] 92: [WARNING] Updated didn't matched the inserted! Inserted: 10, Updated: 9 Node 2 Status Before: After: Change: wsrep_local_bf_aborts 155 159 4
The "50" before WARNING is the transaction number. So the above log (from a custom script) shows five errors where the UPDATE only found 9 rows out of 10 to update. If two consecutive transactions generated a wsrep_local_bf_aborts, it seems like the status number doesn't get updated.
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Jan, where do you "see 4 transactions"? As Will noted, there are 100 update transactions and 5 of them update fewer rows than were inserted immediately prior. There are WARNINGs shown for 5 transactions: 50, 55, 78, 79, 92. The question, as I understand it, is: why is wsrep_local_bf_aborts incremented only 4 times even though 5 update transactions found fewer rows than were inserted.
Yes, I see the warnings, that is not I would need to know. I need full, unedited server log from both servers. wsrep_local_bf_aborts in Galera documentation states that this is the:
Total number of local transactions that were aborted by slave transactions while in execution.
Instead of a local transaction triggering the failure on commit, this is triggered by Galera replication threads applying replicated transactions.
To be clearer: a transaction was open on this node (not-yet-committed), and a conflicting writeset from some other node that was being applied caused a locking conflict. Again, first committed (from some other node) wins, so our open transaction is again rolled back. ”bf” stands for brute-force: any transaction can get aborted by galera any time it is necessary.
Thus, this variable is not increased when transaction is aborted on a first local server.
Closing as no real issues was found.
Hi, I'm little bit confused, based on output I see 4 transactions (i.e. 4 update transactions) and that is also seen on wsrep_local_bf_aborts, i.e. 4 transactions were bf aborted. Variable does not count how many rows there were.