OK, I have rebuilt my Ubuntu 16.04 test server from scratch with MySQL loaded and running.
The bad news is that I can definitively say that Bacula with MySQL 5.7 runs something like 10 times slower than it did with the prior version of MySQL as well as ~10 times slower than Postgres.
The good news is that I had some time while rebuilding the server, and I successfully figured out what the problem is. When Bacula is doing big inserts (we call it batch insert) at the end of the job, it batches the metadata all together in transactions of 25,000 insertions at a time for insertion into the catalog (DB), but this batching is only done if MySQL is multi-threaded, and the old code tests explicitly for libmysqlxxx_r prior to even trying mysql_thread_safe(). So on any current Bacula with MySQL 5.7 there is no batch insert and a huge performance hit.
I have made a first quickie patch and it seems to be working (now MySQL is only ~20-50% slower than the out-the-box postgres, which is normal).
I will get back to you with a correct patch either later today or tomorrow (once I commit it).
OK, I have rebuilt my Ubuntu 16.04 test server from scratch with MySQL loaded and running.
The bad news is that I can definitively say that Bacula with MySQL 5.7 runs something like 10 times slower than it did with the prior version of MySQL as well as ~10 times slower than Postgres.
The good news is that I had some time while rebuilding the server, and I successfully figured out what the problem is. When Bacula is doing big inserts (we call it batch insert) at the end of the job, it batches the metadata all together in transactions of 25,000 insertions at a time for insertion into the catalog (DB), but this batching is only done if MySQL is multi-threaded, and the old code tests explicitly for libmysqlxxx_r prior to even trying mysql_thread_ safe(). So on any current Bacula with MySQL 5.7 there is no batch insert and a huge performance hit.
I have made a first quickie patch and it seems to be working (now MySQL is only ~20-50% slower than the out-the-box postgres, which is normal).
I will get back to you with a correct patch either later today or tomorrow (once I commit it).