Bug #100363 | clone_valid_donor_list causes initialization failures | ||
---|---|---|---|
Submitted: | 29 Jul 2020 9:16 | Modified: | 14 Jan 2021 16:27 |
Reporter: | Daniël van Eeden (OCA) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Clone Plugin | Severity: | S3 (Non-critical) |
Version: | 8.0.21 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | Clone, cloning, usability |
[29 Jul 2020 9:16]
Daniël van Eeden
[29 Jul 2020 12:04]
MySQL Verification Team
Hello Daniël, Thank you for the report and feedback. Verified as described. regards, Umesh
[29 Jul 2020 14:50]
Daniël van Eeden
Another solution may be to put plugin config in different sections [mysqld] plugin_load_add='clone=mysql_clone.so' [clone] clone_valid_donor_list=myhost:3306 The failing on missing variables in the mysqld section can remain critical and the plugin settings can be handled only if the plugin is active. Maybe use a prefix like [plugin__clone] instead of [clone] to make things more explicit.
[13 Jan 2021 14:23]
Georgi Kodinov
Posted by developer: First of all I'd like to state that this is working as documented, albeit in the release notes. https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html says: When the server is run with --initialize, there is no reason to load non-early plugins. The server now logs a warning and ignores any --plugin-load or --plugin-load-add options given with --initialize. (Bug #29622406) Maybe the documentation can be expanded a bit, but it is an intentional behavior. And also the fact that unknown options prevent mysqld from starting is also well known behavior. This makes the bug report a feature request technically. Marking the bug as such. Now on ways to fix this: I do not think that currently --initalize needs any external plugins to perform its function. On the contrary: the server is in such a limbo state at init time that allowing arbitrary plugins to load during that time is probably not a very sustainable. As for fixing the issue. Unfortunately there's very little one can do to fix this issue as it's a well-known consequence from the architectural decision of having options for dynamically loadable components interwoven with the server options. This leaves the server with no way of distinguishing between a misspelled and a correctly-spelled-but-for-a-missing-plugin option. We are working on a solution for this covering components but it's a feature and not a bug fix as it changes architecture. In the meanwhile I would suggest workarounds: 1. use --defaults-extra-file for the plugin-related variables and do not pass that during --initialize 2. use SET PERSIST[_ONLY]: this automatically prefixes with --loose behind the scenes.
[14 Jan 2021 16:27]
Daniël van Eeden
Thanks for the explanation. I agree that this is a feature and that there is not really a good and easy fix right now. Would having sections in the my.cnf for plugins work? e.g.: ================= [mysqld] plugin-load-add='clone=mysql_clone.so' [plugin_clone] valid_donor_list=myserver.example.com:3306 ================== Instead of: ================== [mysqld] plugin-load-add='clone=mysql_clone.so' clone_valid_donor_list=myserver.example.com:3306 ==================