On 2020-07-15 09:19, 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.
The part that puzzles me about this is that the behavior would be different between MySQL and MariaDB. Granted, MariaDB and MySQL have diverged increasingly over the past few years (and I still think Monty Widenius did the MySQL community no favors when he decided he wanted to take back giving MySQL to Sun Microsystems). But they are still very, very close to functionally identical. That said, the documentation for MariaDB, MySQL, Percona Server, and Galera will all tell you that in the event of a deadlock, or anything else that causes a query to be rolled back, it is the application's responsibility to examine the return result and decide, depending on the transaction, whether it should be resubmitted (and possibly amended or updated first). Galera DOES actually provide a configuration variable to set a number of automatic retries of local commit *errors*, in which a single node is unable to apply a writeset that the cluster has already unanimously agreed to commit, but that concept is not applicable to standalone MySQL/MariaDB/Percona servers, and it is unique in that — none of the underlying engines provide it. Since the requirements for and importance of individual queries can vary, any automatic retry would have to be a policy set by the calling application on each individual query. This might end up being more work than simply checking the return code and deciding whether to resubmitting in the case of a rollback, especially since best practices for ANY relational database call for always checking the return code in any case. Fundamentally, you would simply be making the decision *in advance* of whether the query should be automatically resubmitted if it is rolled back (as distinct from it failing), and notifying the database of that policy. However, I wouldn't expect to see such a functionality in any SQL database engine any time soon. It's the application's job to decide how to handle rollbacks and failures, and simply treating all non-success results as fatal errors is not a correct way to do it. > 2. I personally have the time/energy to support MariaDB even if it is > becoming the open source replacement for MySQL. Happily I think that is overstating the case somewhat, but I still think that the forking of MariaDB from MySQL has overall harmed the MySQL community, by fracturing it for no sound technical reason. It was ultimately a political decision by Monty Widenius. > 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. Honestly, I do enterprise-level database support for the largest managed cloud/managed hosting company in the world, and I have yet to see a customer application that did not work equally well against equivalent branches of MySQL and MariaDB. This is not to say that there might not be tweaks that could make Bacula work better with it though, especially as they continue to increasingly diverge. I would personally think that for Bacula Systems, a more important choice would be to support Bacula on HA peer-to-peer clusters, be it a Galera-based cluster such as MariaDB Galera Cluster or Percona XtraDB Cluster, or Oracle's Paxos-based MySQL InnoDB Cluster. Of the two, MySQL InnoDB Cluster is the tougher problem, due both to details of how the Paxos algorithm works¹ and how it replicates between nodes². Oracle does not like to acknowledge these issues and will vigorously argue that they are unimportant or that Galera does just the same (it doesn't). ¹ Galera uses a full-consensus algorithm in which all nodes must be unanimous. The Paxos algorithm commits on agreement of a quorum of nodes, the remaining nodes being eventually consistent. This raises the possibility that one job thread could think it is seeing the current version of data that other nodes have already changed. ² Galera uses fully parallelized replication on a transaction-by-transaction basis, with multiple transactions being replicated simultaneously up to the number of provisioned replication threads. MySQL InnoDB Cluster relies upon serialized replication channels on which a single large transaction can delay replication of others after it. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
