On 12/23/20 11:00 AM, Sebastian Suchanek wrote: > Am 23.12.2020 um 05:21 schrieb Gary R. Schmidt: > >> [...] >> I would suggest moving to PostgreSQL rather than MariaDB. >> >> PostgreSQL is fully supported by Bacula, MariaDB has thrown up a few >> nasties where is is not quite the same as MySQL, and those will probably >> increase. >> [...] > > Just out of curiosity: what "nasties" would that be? I'm running MariaDB > as a replacement for MySQL for some years now (both for Bacula and for > my own projects) and haven't had any issues so far.
My personal experience is the following: 1. A few features of Bacula and its MySQL driver do not work well with Galera CLUSTERED MySQL/MariaDB, but work fine with a standalone server. In particular, if you are running Bacula backed by a Galera cluster, you must disable attribute spooling, or any job containing more than 128K files will fail, because the internal parameter that is supposed to control the batch size of inserts in Bacula's mysql driver is non-functional. 2. RECENT versions of both MySQL and MariaDB implement more strict SQL compliance which is problematic for Bacula because of ways in which it violates the SQL99 standard, or in some cases used to violate SQL99 but has since been fixed. These include but are not limited to: - NOT NULL without a valid DEFAULT (violates SQL99 because you've told mysqld a column is not allowed to be NULL, but haven't told it what it should replace missing values with); - 0000-00-00 00:00:00 as a default DATETIME (violates SQL99 because it is an invalid date, since there is no year 0, month 0, or day 0). 3. The MAJORITY of problems that most people get into using MySQL/MariaDB for ANY purpose result from using it straight out of the box, untuned and unsecured, because they don't know that it is supposed to be tuned. For most of the last ten years I have been working for large managed hosting providers doing enterprise MySQL support, and you would be horrified at the number of production databases I have seen with no root password and/or still using insecure MySQL 3.23 authentication because nobody had ever told them they needed to do anything different. (Much of this was Red Hat's fault. Red Hat shipped MySQL for nearly fifteen years with a default configuration in which only one directive actually did anything, and that one directive was actively harmful.) Recent MySQL releases at least force you to secure it, but the default state of tune out-of-the-box is still very inadequate. PostgreSQL evangelists like to point out that in PostgreSQL, "very little tuning is necessary"; the other side of this coin is that in PostgreSQL, very little tuning is even *possible*. There is also in recent years the progressive drift *BY DESIGN* of MariaDB away from MySQL compatibility. At this point, MariaDB and MySQL are neither binary nor replication compatible any longer and must be regarded as separate database cores. MariaDB GTIDs are subtly different from MySQL GTIDs; MySQL 8 no longer has .frm files and uses a real internal data dictionary, but MariaDB does not support it. (To name two differences.) And then there's MariaDB's Aria storage engine, which is neither fish nor fowl nor good read meat, supposed to be able to be either transactional or not, which sounds to me like an incredibly bad idea. I think MariaDB also still allows you to get away with certain SQL99 violations which MySQL does not. This has fragmented the MySQL user community, with Linux distributions almost invariably switching to MariaDB while business users generally stick with MySQL or Percona Server for which they can get vendor support if they need it. MOST OF THESE THINGS, you will not run into if you are using a single standalone server instance and not doing anything complex or unusual with it. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.695 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
