Re: Hung jobs: continued diagnosis

Kern Sibbald <[email protected]>
Newsgroups gmane.comp.sysutils.backup.bacula.devel
Message-ID <[email protected]>
Sorry, correction:

2. I personally do *not* have the time/energy to support
MariaDB even if it is becoming the open source replacement for
MySQL.

Kern

On 7/15/20 3:19 PM, Kern Sibbald wrote:

Hello,

There are a few things to keep in mind concerning MariaDB:

1. The Bacula project currently does not support MariaDB. One of
the reasons is when testing Bacula with MariaDB, running *exactly*
the same jobs as I ran with MySQL, MariaDB fails with the deadlock
messages you have seen. To me that is a bug in MariaDB any
waiting and retrying should be done within the MariaDB API
(possibly configurable). For me, it makes no sense to push the
retry effort back to the external calling program.

2. I personally have the time/energy to support MariaDB even if it
is becoming the open source replacement for MySQL.

3. I am not opposed to supporting MariaDB, but it is a big effort,
possibly involving coding retries (that should be done by MariaDB
itself, IMO), and requiring a lot of testing.

4. Any support of MariaDB will need to wait for one of two things:

a. A community patch for the retry (that does not mess up
MySQL or Postgres support), including a certain commitment to help
maintain Bacula support for MariaDB.

b. Bacula Systems is considering supporting MariaDB, so if
they do support it, then the support issues around MariaDB go
away.

If you want a stable Bacula Database that does not have problems,
I recommend that you use either MySQL or PostgreSQL. Postgres is
a bit harder to setup since it requires tighter security on
installation, but if setup according to the Bacula documented
parameters, it is faster that MySQL, it handles bigger jobs, and
it is more stable. I understand that complicated setups like
Phil's may be very hard (impossible) to do with MySQL and would
also be difficult to do with Postgres, though with Postgres, they
would probably end up being much better.

Best regards,

Kern

On 7/15/20 2:56 PM, Phil Stracchino wrote:

On 2020-07-15 01:50, Sven Hartge wrote:

Looking at my logs, I have seen the same
in my 9.6.5 installation on

Debian 10:

Excerpts from Error/Canceled-Mails:

-----

24-Jun 00:02 back-dir JobId 585301: Error: bdb.h:140 bdb.h:140
update

UPDATE Job SET JobStatus='R',Level='I',StartTime='2020-06-24

00:02:58',ClientId=73,JobTDate=1592949778,PoolId=7,FileSetId=427 WHERE

JobId=585301 failed:

Deadlock found when trying to get lock; try restarting
transaction

24-Jun 00:02 back-dir JobId 585301: Fatal error: bdb.h:140
update UPDATE

Job SET JobStatus='R',Level='I',StartTime='2020-06-24

00:02:58',ClientId=73,JobTDate=1592949778,PoolId=7,FileSetId=427 WHERE

JobId=585301 failed:

Deadlock found when trying to get lock; try restarting
transaction

-----

28-Jun 00:02 back-dir JobId 586375: Error: bdb.h:140 bdb.h:140
update

UPDATE Job SET JobStatus='R',Level='I',StartTime='2020-06-28

00:02:24',ClientId=149,JobTDate=1593295344,PoolId=7,FileSetId=153 WHERE

JobId=586375 failed:

Deadlock found when trying to get lock; try restarting
transaction

28-Jun 00:02 back-dir JobId 586375: Fatal error: bdb.h:140
update UPDATE

Job SET JobStatus='R',Level='I',StartTime='2020-06-28

00:02:24',ClientId=149,JobTDate=1593295344,PoolId=7,FileSetId=153 WHERE

JobId=586375 failed:

Deadlock found when trying to get lock; try restarting
transaction

-----

09-Jul 00:04 back-dir JobId 589511: Error: bdb.h:140 bdb.h:140
update

UPDATE Job SET JobStatus='R',Level='I',StartTime='2020-07-09

00:04:16',ClientId=255,JobTDate=1594245856,PoolId=7,FileSetId=408 WHERE

JobId=589511 failed:

Deadlock found when trying to get lock; try restarting
transaction

09-Jul 00:04 back-dir JobId 589511: Fatal error: bdb.h:140
update UPDATE

Job SET JobStatus='R',Level='I',StartTime='2020-07-09

00:04:16',ClientId=255,JobTDate=1594245856,PoolId=7,FileSetId=408 WHERE

JobId=589511 failed:

Deadlock found when trying to get lock; try restarting
transaction

-----

This is with a remote MariaDB 10.3 server, i.e. the database
is not on

the same server but exclusive for Bacula.

Thanks for confirming, Sven. A deadlock should not be a fatal
error, it

should be retried.

_______________________________________________

Bacula-devel mailing list

[email protected]

https://lists.sourceforge.net/lists/listinfo/bacula-devel

_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.