Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Won't Fix
-
None
-
None
Description
Right now mysql_upgrade does not check whether installed plugins can actually be loaded.
This is especially an issue when upgrading from MySQL to MariaDB, where e.g. validate_password.so might be installed which does not exist in MariaDB.
Right now mysql_upgrade does only check for the presence of needed storage engine plugins, all other missing plugins will only be noticed on server startup and error messages will be written to the error log, where they might get overlooked.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
I don't think it's an issue yet. mysql_upgrade should not check all plugins, it's not part of the upgrade. If MariaDB had a dynamic plugin in some version and it was later removed (for example, semisync), then removing it from mysql.plugin table on upgrade seems reasonable and that's something mysql_upgrade can, perhaps, do.
But we don't remove plugins often, so I am not sure this special case requires dedicated support in mysql_upgrade. This semisync case is the only one I can remember where a plugin was integrated into the server.
> Please take into account that a failure upon mysql_upgrade may have unpleasant side effects.
I don't want it to fail, I just want it to report the missing plugin library. Right now this can only be seen in server startup messages in the error log, or when knowing what to check for in SHOW PLUGINS, neither of which typical users will do.
I don't want mysql_upgrade to fix it, just having it tell users that there is something they need to figure out instead of just pretending that the upgrade went all fine ...
> If MariaDB had a dynamic plugin in some version and it was later removed ...
Well, it's more of a problem when moving from MySQL to MariaDB right now, especially when it comes to "validate_password" on the MySQL side ...
"why is that important for the customer to get this fixed?"
It is less critical now that the audit plugin startup deadlock is fixed.
IMHO mysql_upgrade should warn about all potential upgrade problems, even those that it can't fix itself. And no longer being able to use a plugin that was installed in the previous version is such a problem. The server will also complain about this in the error log during startup, but we know that users often do not check the error log at all ...
julien.fritsch I replied to your question from Jan 14th on the next day, so I don't think it is waiting for my feedback?
Assigning to serg for evaluation.
Please take into account that a failure upon mysql_upgrade may have unpleasant side effects. I think some of our package installation/upgrades (debs?) run mysql_upgrade as a part of the process, and they aren't good at rolling back; it means that installation will fail and the package structure will remain inconsistent. Users might not appreciate it.