Hello again,
I just thought I'd update this post with more information in hopes of getting some explanation for the deadlocks.
I ran with Accurate backup on our test VMs (RHEL) for a couple of days and got the same errors on some VMs that were running accurate and some that were not. These hosts were running concurrently. I would say 90% of the hosts that were configured to use Accurate finished successfully. However, there were a few that failed with the deadlock error -- some that were configured to use accurate and some that were not configured to use accurate. Also, on all of these, a second job started for each of the affected hosts right after Bacula detected the deadlock even though it said a reschedule would happen 3600 seconds later (the 3600 seconds is correct).
Tonight, I disabled accurate on all hosts and the deadlocks did not happen. No errors were detected and all the backups finished successfully.
Some questions...
1. Can I back up multiple hosts concurrently with some hosts configured to use accurate and some configured not to use accurate? Or, is it an all or none thing, meaning all hosts that run concurrently must either be using accurate backup or not using accurate backup (cannot mix the two)?
2. It seems like the hosts that get out of the starting gate first are the ones affected. I am configured to run 50 jobs concurrently. Again, no problems with accurate turned off on all hosts for months now.
3. Why is Bacula spinning off a new job right away after it detects the deadlock for each affected job instead of waiting until the rescheduled job runs? I verified that there were no duplicate jobs in the queue before the backups started running, no jobs were running before the start of the backups, and I did not start any of these backups manually to cause a second job to appear.
From the INNODB Monitor output:
TRANSACTION:
TRANSACTION 208788977, ACTIVE 1 sec setting auto-inc lock
mysql tables in use 4, locked 4
9 lock struct(s), heap size 1184, 5 row lock(s)
MySQL thread id 50808, OS thread handle 0x7f8f2c3b4700, query id 29558637 <host> 192.168.10.99 bacula Sending data
INSERT INTO File (FileIndex, JobId, PathId, FilenameId, LStat, MD5, DeltaSeq) SELECT batch.FileIndex, batch.JobId, Path.PathId, Filename.FilenameId,batch.LStat, batch.MD5, batch.DeltaSeq FROM batch JOIN Path ON (batch.Path = Path.Path) JOIN Filename ON (batch.Name = Filename.Name)
WAITING FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `bacula`.`File` trx id 208788977 lock mode AUTO-INC waiting
WE ROLL BACK TRANSACTION (2)
I am running Bacula 7.0.5 on RHEL 6.6 x64 with Director, Storage and Catalog running on separate RHEL 6.6 hosts. Our clients are RHEL 6's, 5's and Windows Servers 2008 and 2012R2.
Any help would be much appreciated.
Warmest regards,
-craig