[MDEV-16067] Invalid deadlock detection Created: 2018-05-01  Updated: 2018-09-17  Resolved: 2018-09-17

Status: Closed
Project: MariaDB Server
Component/s: Locking, Server, Storage Engine - InnoDB
Affects Version/s: 10.1.32, 10.2.14
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: azurit Assignee: Alice Sherepa
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Debian Stretch, 64bit

Attachments: File my.cnf    
Issue Links:
Duplicate
duplicates MDEV-13333 Deadlock failure that does not occur ... Closed

 Description   

After upgrading from Debian Jessie to Debian Stretch using MariaDB 10.1.32 packages from mariadb.org, we immediately started having problems with our backup software, Bacula ( www.bacula.org ) - the backup jobs are failing with this error:
Deadlock found when trying to get lock; try restarting transaction

This is happening every night for different backup jobs (probably random) and has NEVER happened before. While upgrading Debian, there was only a minor version change of Bacula (7.4.3 to 7.4.4). From my observation, error is happening for randomly for same SQL commands, sometimes after 300 seconds, sometimes after 2000 seconds of execution/waiting for locks. This is happening even after i set this:
innodb_lock_wait_timeout = 100000

I also tried upgrading to 10.2.14 and set this:
innodb_deadlock_detect = 0

Which does nothing, problem persists.

 Comments   
Comment by Elena Stepanova [ 2018-05-01 ]

azurit,

  • from which version did you upgrade?
  • please paste or attach your config file(s).

mleich, could you please take a look into this, whether we have a regression in 10.1.32 comparing to the version that azurit used before?

marko, do you think it might be related to recent changes in persistent statistics?

Comment by azurit [ 2018-05-01 ]

Before Debian upgrade, we used MariaDB 10.1.32 for Debian Jessie from mariadb.org, after upgrade we used the same version (10.1.32) also from mariadb.org but for Debian Stretch (we correctly set the Debian version in repository settings before upgrade). Attaching my.cnf.

I know that the version of MariaDB didn't change but, for example, why am i getting that error even with innodb_deadlock_detect = 0 ?

Comment by azurit [ 2018-05-01 ]

I just found MDEV-13333 , which was opened by Bacula author.

Comment by Elena Stepanova [ 2018-05-01 ]

alice, you did a lot of work on MDEV-13333, do you remember anything about it?

From comments there it appears that the problem occurred on 10.2 but not on 10.1, which is somewhat understandable. Can you think of any explanation why the behavior could change on the same MariaDB version only after Bacula upgrade and switching from MariaDB server packaged by MariaDB to Debian packages? Some changes in Bacula scripts, maybe? Or a difference in configuration files in MariaDB packages vs Debian's?

Comment by azurit [ 2018-05-11 ]

I was able to downgrade to 10.1 and problem seems to be gone.

Comment by Alice Sherepa [ 2018-07-02 ]

azurit, it looks like it is the same problem as MDEV-13333, so I suggest to wait for MDEV-13333 to be fixed.
If the bug will be still reproducible, then it will be investigated further.

Comment by Jan Lindström (Inactive) [ 2018-08-06 ]

@azurit try set global innodb_lock_schedule_algorithm=FCFS;

Comment by azurit [ 2018-08-06 ]

I'm, currently, on 10.1 so it is already set to 'fcfs'. The problem is still occuring but it's not so often as on 10.2. Any suggestions how to bypass it on 10.1? It is really doing us lots of trouble.

Comment by Alice Sherepa [ 2018-09-11 ]

azurit MDEV-13333 is fixed now, are you able to try 10.1.36 to confirm that the problem is solved?

Comment by azurit [ 2018-09-17 ]

I cannot tell for 100%, because the problem was appearing randomly, but it looks good so far. Thank you!

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