Bug #100363 clone_valid_donor_list causes initialization failures

Description:
If I add this to the my.cnf:
plugin-load-add='clone=mysql_clone.so'
clone_valid_donor_list=myhost:3306

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.

Hello Daniël,

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

regards,
Umesh

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.

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.

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