8

I have a MySQL 5.6 server which we monitor using Nagios.

Over the weekend, it's started complaining about the Innodb_row_lock_current_waits, which currently has a value of 18446744073709551615, yes, that's more than 10^19! As I understand it, this value is the number of current row locks. Basically, I don't believe it, that number is far too large?

As Phil pointed out, the number is 2^64 - 1, so now my question is: Why is MySQL returning this number, it must be an overflow/error code of some sort.

0

2 Answers 2

3
+250

There is a open bug report on this for MySQL 5.6.14

Bug #71520 Constantly increasing Innodb_row_lock_current_waits value

From the bug report, note this entry

[25 Jun 2015 6:58] Zhenye Xie in my environment, I got a strange value. (-1 as uint64)

mysql> show status where Variable_name = 'Innodb_row_lock_current_waits';

+-------------------------------+----------------------+
| Variable_name                 | Value                |
+-------------------------------+----------------------+
| Innodb_row_lock_current_waits | 18446744073709551615 |
+-------------------------------+----------------------+
1 row in set (0.06 sec)

in lock0wait.cc, srv_stats.n_lock_wait_current_count.inc() srv_stats.n_lock_wait_current_count.dec(); is not thread safe. srv_stats is a global variable, but it has just a lock on trx surrounds changing the value.

You were right when you said it must be an overflow/error code of some sort

As recent as Jun 14 of this year, this issue may or may not exist in MySQL 5.7.11

[14 Jun 9:55] Ángel OR Good morning,

I am seeing this in MySQL 5.7.11-log:

mysql> show status like '%Innodb_row_lock_current%';

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 45    |
+-------------------------------+-------+
1 row in set (0.00 sec)

mysql> select count(*) from information_schema.innodb_lock_waits;

+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

mysql> select version();
+------------+
| version()  |
+------------+
| 5.7.11-log |
+------------+
1 row in set (0.00 sec)
3
  • It doesn't appear to be 'continually increasing'. It suddenly jumped from 0 to this value. Jul 4, 2016 at 14:54
  • You just verified that the bug is very much alive and kicking. Jul 4, 2016 at 16:09
  • My bug seems different from the one linked - the value does not 'continually increase', the value jumped from 0-'overflow', it did not pass through intermediate values. I see a comment in the linked bug which mentions the same behaviour that I see, but it's not the same as reported in the bug description. Jul 5, 2016 at 14:25
1

MySQL has other cases of -1 being stored into an UNSIGNED field. Report it via http://bugs.mysql.com , then don't worry about it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.