Description of problem:
The mysqldump task that runs as part of the catalog backup process does not work properly in Fedora 34 with mariadb-server and mysqldump from community-mysql 8.x:

11-Jun 08:20 tycho-dir JobId 8168: shell command: run BeforeJob "/usr/libexec/bacula/make_catalog_backup.pl MyCatalog"
11-Jun 08:20 tycho-dir JobId 8168: BeforeJob: mysqldump: Couldn't execute 'SELECT COLUMN_NAME,                       JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')                FROM information_schema.COLUMN_STATISTICS                WHERE SCHEMA_NAME = 'bacula' AND TABLE_NAME = 'BaseFiles';': Unknown table 'COLUMN_STATISTICS' in information_schema (1109)
(repeated for many tables).
11-Jun 08:22 tycho-dir JobId 8168: Error: Runscript: BeforeJob returned non-zero status=2. ERR=Child exited with code 2
11-Jun 08:22 tycho-dir JobId 8168: Error: Bacula tycho-dir 11.0.3 (21Mar21):

This seems to be because in version 8.0 of community-mysql onwards, the mysqldump command tries to do column statistics by default, which are not supported by mariadb:
https://serverfault.com/questions/912162/mysqldump-throws-unknown-table-column-statistics-in-information-schema-1109

I have been able to work around this issue by creating /etc/my.cnf.d/zz-no-column-statistics.cnf on my database server, with content:

>>>---------
# MySQL 8 turns on column statistics by default, which is not compatible with MariaDB
# https://serverfault.com/questions/912162/mysqldump-throws-unknown-table-column-statistics-in-information-schema-1109

[mysqldump]
column-statistics=0
<<<---------

A better fix might be to patch the /usr/libexec/bacula/make_catalog_backup.pl script to run mysqldump with the "--column-statistics=0" option specified.