Hello Phil, Please see my comments below ...
On 6/25/19 12:33 AM, Phil Stracchino wrote:
First up: Backup to CD has long since been abandoned and, if I'm not mistaken, *removed*. Why does the Bacula schema still contain a CDImages table?
To remove it requires a new catalog version number, and when I do update it (probably in the next major release), I generally forget to remove those old tables.
Would you please spend the time to write a bug report on this particular item, so that I can hope to remember it for the next release.
The current source has Version 16. My current database is version 16. It's been fully updated to current. The version 16 make_mysql_tables file creates a PathHeirarchy table. My schema doesn't contain it, and neither any of the updatedb/update_mysql_tables_* scripts nor src/cats/update_mysql_tables creates it.
I will ask the developer, but I am about 90% sure it is an Enterprise feature. We are trying to make the Enterprise code base and catalog format the same as the Community (or rather vice-versa) so in a few cases there may be unused tables.
Should it even exist? Is it a table for Enterprise-only functionality? Is it a table for planned FUTURE functionality? If it *should* exist, shouldn't update_mysql_tables create it?
I will ask.
Next, and what spurred this: I was doing routine performance checks on my DB and noticed that the Bacula schema still has several BLOB columns, most of them tiny. This is generally a bad idea in MySQL, because it forces temporary tables to disk no matter how small, because the MEMORY storage engine does not support BLOB or TEXT types. Now, I've modified my schemas a long time ago to replace all but a very few of the BLOB columns with VARBINARY. (VARBINARY is to VARCHAR as BLOB is to TEXT.) In general, I have replaced TINYBLOBs with either varbinary(32), varbinary(64), or varbinary(255); there is one varchar(100) and one varbinary(4096). I have tried to err on the side of more space than needed, if in doubt. There's a couple of BLOBs left that I haven't touched, two in RestoreObject, one in Log. The one in Log I have left alone because it clearly could be long. The two in RestoreObject I have left alone because I don't know what they're for and don't know what the lengths might be and what the impact might be. (There's also just a few indexing changes, most of them resulting from changing TINYBLOBs to VARBINARYs.) I have been running with these changes for over a year and have not seen any resulting problems. I HAVE seen improved database performance due to almost completely eliminating on-disk temporary tables. Comments welcomed.
Yes, I welcome this kind of change. The biggest problem I have to make these kinds of changes is that I worry about compatibility as I no longer have the means to test on older MySQLs and ensure compatibility with MariaDB even if we do not officially support it. Judging from what you wrote, this should not be an issue.
Would you please submit this patch as a bug report (not a feature request). That way, I can get it integrated into the next major version (probably will release as Bacula version 11.0.0 ....).
I have already received a previous submission containing some MySQL changes and a bunch of suggestions. You may have seen it. My big problem as I mentioned was ensuring compatibility and at the time of that submission I had no one to test these sorts of things. I believe you saw that submission, in which case, I would be interested in your current comments on it. If not, please let me know and I will try to find it and send it to you.
Best regards, Kern _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
