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
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
