Bug #59026 Allow multiple --plugin-load options
Submitted: 18 Dec 2010 16:56 Modified: 31 Aug 2011 14:38
Reporter: Paul DuBois Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Options Severity:S4 (Feature request)
Version:5.x OS:Any
Assigned to: Geir Høydalsvik CPU Architecture:Any

[18 Dec 2010 16:56] Paul DuBois
Description:
The --plugin-load option used to load plugins at server startup has this syntax:

--plugin-load=plugin_name=obj_file[;plugin_name=obj_file]...

That is, one or more comma-separated name/file pairs. If multiple --plugin-load options are given, only the last one is used by the server.

However, the pluggable architecture of MySQL encourages development of plugins, and we see this happening with, for example, semisync replication, authentication plugins, audit plugins. As this trend continues, it becomes more likely that a DBA will have an increasing list of plugins to be loaded.

The current syntax requires all plugins to be named with a single --plugin-load option. This has some disadvantages:

* The option line becomes longer and more error-prone to write
* Longer option lines are harder to read -- e.g., does it name a particular plugin or not?
* Longer option lines are harder to modify -- e.g., you want to just comment out a particular plugin

A subsidiary problem is that longer option lines make it more difficult to write documentation that exactly reflects practice: The manual cannot include a really long line, it must break it into many lines and instruct the user "enter this all on one line, without spaces".

Possibly there is a risk of buffer limits being exceeded if the line gets long enough?

I request that the server accept multiple --plugin-load options and process them all (analogous to options such as --replicate-do-db and --replicate-ignore-db). Then users could more easily add and subtract (or comment out) plugins to be loaded, and documentation could exactly reflect practice without having to add caveats.

How to repeat:
N/A

Suggested fix:
N/A
[26 Jan 2011 2:43] Lenz Grimmer
For the record, I strongly support this request.
[26 Jan 2011 9:25] Bjørn Munch
How about multiple --plugin-dir, wouldn't that also be needed? Or is it already?
[26 Jan 2011 10:33] Georgi Kodinov
Bjorn,

For the record : I don't think multiple plugin dirs is such a good idea. You have better control when you only have 1 such.
[26 Jan 2011 10:39] Bjørn Munch
To the last comment: yes but that's not how the plugins are organized after a default build; they are placed in different subdirectories of ./plugin. This is also how they're expected to be found by the mtr tests, and I'm thinking of this from that perspective.
[28 Feb 2011 10:33] Ferenc Kovacs
+1 for this.
also until this is implemented, I would suggest to generate a warning on multiple plugin-load.
I was bitten by this: I had multiple plugins (innodb and pinba) and I spent some time debugging why won't my innodb plugin get loaded.
see http://www.dotdeb.org/2011/02/22/mysql-5-1-55-is-available/

however I don't think that having multiple plugin_dir is a must have.
Bjorn: you can control that which plugin is in which directory through plugin-load:
http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_plugin-load
"This option tells the server to load the named plugins at startup. The option value is a semicolon-separated list of name=plugin_library pairs. Each name is the name of the plugin, and plugin_library is the name of the shared library that contains the plugin code. Each library file must be located in the directory named by the plugin_dir system variable. For example, if plugins named myplug1 and myplug2 have library files myplug1.so and myplug2.so, use this option to load them at startup:

shell> mysqld --plugin-load=myplug1=myplug1.so;myplug2=myplug2.so"

so it's not a problem, that plugins are in separate directories under plugin.

Tyrael
[28 Feb 2011 11:15] Bjørn Munch
I don't quite understand the last comment. If plugins are located in different subdirectories under 'plugin', how can the server find both if it can only be given one --plugin_dir option?
[28 Feb 2011 11:27] Ferenc Kovacs
sorry, you are right, I've misunderstood the documentation, and I've tought that you can set the path for the plugin throught the plugin-load.
just tried out and obviously that doesn't work, so as the documentation explicitly states it :"Each library file must be located in the directory named by the plugin_dir system variable." (this is what I've missed).
so I'm +1 for multiple plugin_dir, or better: the ability to pass relative/absolute path for plugin via plugin-load.

Tyrael
[28 Feb 2011 14:55] Paul DuBois
"so I'm +1 for multiple plugin_dir, or better: the ability to pass
relative/absolute path for plugin via plugin-load."

That is a different feature. Please don't load up this bug report with
additional feature requests, open a new report.
[28 Feb 2011 15:27] Ferenc Kovacs
sorry, but that was mentioned already by Bjorn and Georgi, I've just replied to that.

Tyrael
[31 Aug 2011 14:38] Paul DuBois
Noted in 5.6.3 changelog.

A new server option, --plugin-load-add, complements the --plugin-load
option. --plugin-load-add adds a plugin or plugins to the set of
plugins to be loaded at startup. The argument format is the same as
for --plugin-load. --plugin-load-add can be used to avoid specifying
a large set of plugins as a single long unwieldy --plugin-load
argument. 

--plugin-load-add can be given in the absence of --plugin-load, but
any instance of --plugin-load-add that appears before --plugin-load.
has no effect because --plugin-load resets the set of plugins to
load. 

This change affects the output of mysqld --verbose --help in that a
value for plugin-load is no longer printed.