| Bug #88597 | Plugins that happen to be called group_replication cant be uninstalled anymore? | ||
|---|---|---|---|
| Submitted: | 22 Nov 2017 5:05 | Modified: | 22 Nov 2017 11:55 |
| Reporter: | Laurynas Biveinis (OCA) | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server: Group Replication | Severity: | S3 (Non-critical) |
| Version: | 5.7 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | plugin api | ||
[22 Nov 2017 5:54]
MySQL Verification Team
Hello Laurynas, Thank you for the report and feedback. Thanks, Umesh
[22 Nov 2017 11:55]
Nuno Carvalho
Hi Laurynas,
Thank you for your question.
This plugin uninstall restriction was required to avoid a corner
case when this server suffers a majority loss.
On that situation, the UNINSTALL plugin would mark the plugin in
deleted state, while the plugin was still waiting for the current
references to be decremented, which would never happen since the
server was out of the group. Then shutdown server would be executed,
would see plugin as deleted and would do nothing in respect to the
plugin. The plugin would still be waiting for the references and the
shutdown would block.
Instead we block the plugin uninstall when the plugin is in use.
User can do one the of the alternatives:
1) Execute STOP GROUP_REPLICATION which will rollback the blocked
transactions due to majority loss and then uninstall the plugin.
2) shutdown the serve directly, which will call STOP
GROUP_REPLICATION, since the plugin is not deleted.
About the change on plugin.cc, on 5.7, since due to API
compatibility we cannot change the APIs interface, we were forced to
disallow the uninstall this way, on 8.0 it was done through the
proper API update.
Reuse a upstream plugin name, although allowed, you know that it is
not recommended.
Best regards,
Nuno Carvalho
[23 Nov 2017 5:46]
MySQL Verification Team
Are you asking that we have signed plugins, or something similar to authenticate the plugin we're talking about in the code instead of a strcmp?
[23 Nov 2017 7:26]
Roel Van de Paar
Good idea
[23 Nov 2017 7:35]
MySQL Verification Team
Not sure that would be needed though. If somebody can replace a plugin with evil plugin, they can also replace a mysqld with whatever.
Description: 5.7.20 has this fine new code [1] in sql_audit.cc:mysql_uninstall_plugin: if (plugin->ref_count && !strcmp(name->str, "group_replication")) { mysql_mutex_unlock(&LOCK_plugin); my_error(ER_PLUGIN_CANNOT_BE_UNINSTALLED, MYF(0), name->str, "Plugin is busy, it cannot be uninstalled. To force a" " stop run STOP GROUP_REPLICATION and then UNINSTALL" " PLUGIN group_replication."); goto err; } Does that mean, that if I do not install the Oracle group replication plugin and happen to write my own one, which I happen to name "group_replication", it's not uninstallable anymore while in use? How would running this "STOP GROUP_REPLICATION" help in that case? https://dev.mysql.com/doc/refman/5.7/en/plugin-data-structures.html does not list any restrictions for plugin names, for example, that "group_replication" is a reserved name, or similar. [1]: https://github.com/mysql/mysql-server/commit/2d29c4bab2ba0459108f09f1dc1512a810896741 How to repeat: See above Suggested fix: Do not hardcode new plugin names in server layer