Bug #100363 clone_valid_donor_list causes initialization failures
Submitted: 29 Jul 2020 9:16 Modified: 14 Jan 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
If I add this to the my.cnf:

And then run:
`mysqld --initialize-insecure --user=mysql`

This happens:

2020-07-29T09:07:35.292872Z 0 [Warning] [MY-013501] [Server] Ignoring --plugin-load[_add] list as the server is running with --initialize(-insecure).
2020-07-29T09:07:35.695258Z 0 [ERROR] [MY-000067] [Server] unknown variable 'clone_valid_donor_list=myhost:3306'.

Prefixing the variable with `loose_` allows mysqld to initialize.

As initializing and cloning is closely related this is an unfortunate incompatibility.

Not putting the clone_valid_donor_list in the my.cnf but using `SET GLOBAL...` before calling `CLONE...` would work,
but the reason for this setting to exist is to have an extra layer of security, which gets lost if done like this.

How to repeat:
Put clone_valid_donor_list in the my.cnf when initializing mysqld

Suggested fix:
1. Allow certain plugins, like the clone plugin, to be loaded during initialization of mysqld.

2. Have something like `mysqld --initialize-clone myserver:3306` that combines the required steps for initialization and cloning.
[29 Jul 2020 12:04] MySQL Verification Team
Hello Daniël,

Thank you for the report and feedback.
Verified as described.

[29 Jul 2020 14:50] Daniël van Eeden
Another solution may be to put plugin config in different sections



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


Instead of: