[MDEV-22085] mysql_upgrade should check for unavailable plugin libraries Created: 2020-03-30  Updated: 2021-04-19  Resolved: 2021-02-17

Status: Closed
Project: MariaDB Server
Component/s: Upgrades
Affects Version/s: None
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Hartmut Holzgraefe Assignee: Hartmut Holzgraefe
Resolution: Won't Fix Votes: 1
Labels: None

Issue Links:
Relates
relates to MDEV-21873 10.2 to 10.3 upgrade doesn't remove s... Closed
relates to MDEV-21258 Can't uninstall plugin if the library... Closed

 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.



 Comments   
Comment by Elena Stepanova [ 2020-04-01 ]

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.

Comment by Sergei Golubchik [ 2020-04-01 ]

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.

Comment by Hartmut Holzgraefe [ 2020-04-01 ]

> 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 ...

Comment by Timofey Turenko [ 2020-12-21 ]

no, it is not tested in CI yet

Comment by Oleksandr Byelkin [ 2021-01-14 ]

The question how to check plugin presence?

Comment by Hartmut Holzgraefe [ 2021-01-15 ]

"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 ...

Comment by Hartmut Holzgraefe [ 2021-02-15 ]

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?

Generated at Thu Feb 08 09:12:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.