[MDEV-5604] Consecutive wsrep_local_bf_aborts doesn't increase stats Created: 2014-02-03  Updated: 2014-03-11  Resolved: 2014-03-11

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.34-galera
Fix Version/s: 5.5.35-galera

Type: Bug Priority: Major
Reporter: Will Fong Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-5605 Galera BF kill doesn't reflect in wsr... Closed

 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.

 Comments   
Comment by Jan Lindström (Inactive) [ 2014-02-03 ]

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.

Comment by Kolbe Kegel (Inactive) [ 2014-02-04 ]

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.

Comment by Jan Lindström (Inactive) [ 2014-02-05 ]

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.

Comment by Jan Lindström (Inactive) [ 2014-03-11 ]

Closing as no real issues was found.

Generated at Thu Feb 08 07:05:38 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.