wsrep_local_bf_aborts not updating

[Jay Janssen]

[root@node1 ~]# rpm -qa | grep -i percona
Percona-Server-shared-55-5.5.29-rel29.4.401.rhel6.i686
Percona-Server-shared-compat-5.5.29-rel29.4.401.rhel6.i686
percona-toolkit-2.1.9-1.noarch
Percona-XtraDB-Cluster-client-5.5.29-23.7.2.389.rhel6.i686
Percona-XtraDB-Cluster-server-5.5.29-23.7.2.389.rhel6.i686
percona-xtrabackup-2.0.5-499.rhel6.i686
Percona-XtraDB-Cluster-galera-2.0-1.143.rhel6.i686

| wsrep_provider_version | 2.3(r143) |

3 node cluster. Triggering a brute-force abort does not increment wsrep_local_bf_aborts:

Two nodes (in two transactions):

node1 mysql> set autocommit=off;
Query OK, 0 rows affected (0.00 sec)

node1 mysql> select * from test.autoinc;
+---+---------+
| i | j |
+---+---------+
| 2 | default |
| 5 | default |
| 8 | default |
+---+---------+
3 rows in set (0.00 sec)

node1 mysql> update test.autoinc set j="node1" where i = 2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

NO COMMIT

On node3:

node3 mysql> select * from test.autoinc;
+---+---------+
| i | j |
+---+---------+
| 2 | default |
| 5 | default |
| 8 | default |
+---+---------+
3 rows in set (0.00 sec)

node3 mysql> update test.autoinc set j="node3" where i=2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

node3 mysql> commit;
Query OK, 0 rows affected (0.01 sec)

Node 1's transaction aborted as expected:
node1 mysql> select * from test.autoinc;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

But no increment on wsrep_local_bf_aborts:

node1 mysql> show global status like 'wsrep_local_bf_aborts';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| wsrep_local_bf_aborts | 0 |
+-----------------------+-------+
1 row in set (0.00 sec)

[Jay Janssen (jay-janssen)]

Just a quick update. I do see bf_aborts incrementing when doing a load test with two sysbench runs on two nodes. It seems as if it something specific about the manual case above where the cluster is idle otherwise and things are moving slowly.

[Alex Yurchenko (ayurchen)]

It looks like Galera is missing the most common kind of BF simply because it happens way before commit. In fact in some cases Galera may not even be aware of BF'ed transaction existence. So this counter simply must be moved into mysqld.

[Jay Janssen (jay-janssen)]

Will this be (or has it already been) addressed in 3.x?

[Alex Yurchenko (ayurchen)]

I guess it will be - by removing from galera counters. This counter should be in mysqld.