{"id":6579,"date":"2013-10-01T08:50:08","date_gmt":"2013-10-01T06:50:08","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=6579"},"modified":"2013-10-01T08:50:08","modified_gmt":"2013-10-01T06:50:08","slug":"on-mysql-plugin-configuration","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/on-mysql-plugin-configuration","title":{"rendered":"On MySQL plugin configuration"},"content":{"rendered":"

MySQL offers plugin API<\/a>, with which you can add different types<\/a> of plugins to the server. The API is roughly the same for all plugin types: you implement an init() function, a deinit(); you declare status variables and global variables associated with your plugin, and of course you implement the particular implementation of plugin call.<\/p>\n

I wish to discuss the creation and use of global variables for plugins.<\/p>\n

Consider the following declaration of a global variable in audit_login<\/a>:<\/p>\n

\n
static MYSQL_SYSVAR_BOOL(enabled, plugin_enabled, PLUGIN_VAR_NOCMDARG,\r\n\"enable\/disable the plugin's operation, namely writing to file\", NULL, NULL, 1);\r\n\r\nstatic struct st_mysql_sys_var * audit_login_sysvars[] = {\r\n\u00a0\u00a0\u00a0 MYSQL_SYSVAR(enabled),\r\n\u00a0\u00a0\u00a0 NULL\r\n};<\/pre>\n<\/blockquote>\n
The above creates a new global variables called “simple_login_audit_enabled”<\/strong>: it is composed of the plugin name (known to be “simple_login_audit”<\/strong> in our example) and declared name (“enabled”<\/strong>). It is a boolean, defaults to 1<\/strong>, and is associated with the internal plugin_enabled<\/strong> variable.<\/p>\n
Once this variable is declared, you can expect to be able to:<\/p>\n
\n
mysql> show global variables like '%audit%';\r\n+----------------------------+-------+\r\n| Variable_name\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Value |\r\n+----------------------------+-------+\r\n| simple_login_audit_enabled | ON\u00a0\u00a0\u00a0 |\r\n+----------------------------+-------+\r\n\r\nmysql> set global simple_login_audit_enabled := 0;\r\nQuery OK, 0 rows affected (0.00 sec)<\/pre>\n<\/blockquote>\n
and you can expect using the following in your my.cnf<\/strong> file:<\/p>\n
\n
[mysqld]\r\n...\r\nsimple_login_audit_enabled=1<\/pre>\n<\/blockquote>\n
Assuming your server agrees to start<\/h4>\n
Here’s the catch: the simple_login_audit_enabled<\/strong> variable is only recognized as long as the plugin is installed<\/em>. As you may know, plugins can be loaded upon startup time using an explicit my.cnf<\/strong> entry such as:<\/p>\n
\n
plugin_load=audit_login.so<\/pre>\n<\/blockquote>\n
But you may also, at any given time, INSTALL<\/a> or UNINSTALL<\/a> the plugin dynamically.<\/p>\n
\n
install plugin SIMPLE_LOGIN_AUDIT soname 'audit_login.so';\r\nuninstall plugin SIMPLE_LOGIN_AUDIT;\r\n<\/code><\/pre>\n<\/blockquote>\n
In fact there are good reasons to do so: you may be upgrading your plugin. You can’t just throw in the new binary (it’s a guaranteed crash on next server shutdown). You need to first UNINSTALL<\/strong> it; you then put the new binary, and re-INSTALL<\/strong>. This works well, and the price is some downtime for your plugin.<\/p>\n
But what happens if you restart the server while your plugin is uninstalled? Yep: the global variable is unrecognised, and your MySQL server refuses to start:<\/p>\n
\n
130919\u00a0 8:11:30 [ERROR] \/usr\/bin\/mysqld: unknown variable 'simple_login_audit_enabled=1'<\/strong>\r\n130919\u00a0 8:11:30 [ERROR] Aborting<\/strong>\r\n130919\u00a0 8:11:30\u00a0 InnoDB: Starting shutdown...\r\n130919\u00a0 8:11:31\u00a0 InnoDB: Shutdown completed; log sequence number 40185651\r\n130919\u00a0 8:11:31 [Note] \/usr\/bin\/mysqld: Shutdown complete<\/pre>\n<\/blockquote>\n
I did happen on this case a couple times; it is frustrating.<\/p>\n
What are the alternatives?<\/h4>\n
So adding variables to my.cnf may prevent MySQL from starting. In my dictionary, this spells “NO GO”<\/strong>.<\/p>\n
With audit_login<\/strong> I chose to (additionally) support an external config file, audit_login.cnf<\/strong>, expected to be found in the @@datadir<\/strong>. It is similar in essence to the master.info<\/strong> file which is expected by replication.\u00a0The plugin reads this file (if existing) upon init(), which makes it execute upon server startup or upon INSTALL PLUGIN<\/strong>. I can’t argue that this is the best solution, but it is a solution that does not interfere with anyone. The file is ignored by all and does not disturb the public peace. The plugin does not require it to exist.<\/p>\n
I was hoping to be able to directly read from my.cnf<\/strong>, but am unsure if there is a definitive way to do so from within the plugin. I did not go deep into this.<\/p>\n
What would be best?<\/h4>\n
Hopefully I’m not missing on anything. But it would be nice to have plugin-dedicated variables in my.cnf which are ignored by the server. These could take the form of:<\/p>\n
\n
[mysql_plugin]\r\nsimple_login_audit_enabled=0<\/pre>\n<\/blockquote>\n
or similar. It would be the server’s responsibility to pass these declarations to the plugins, but ignore them itself (or just pass warning).<\/p>\n","protected":false},"excerpt":{"rendered":"
MySQL offers plugin API, with which you can add different types of plugins to the server. The API is roughly the same for all plugin types: you implement an init() function, a deinit(); you declare status variables and global variables associated with your plugin, and of course you implement the particular implementation of plugin call. […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[11,120,80],"class_list":["post-6579","post","type-post","status-publish","format-standard","hentry","category-mysql","tag-configuration","tag-development","tag-plugin"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-1I7","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/6579","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=6579"}],"version-history":[{"count":9,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/6579\/revisions"}],"predecessor-version":[{"id":6602,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/6579\/revisions\/6602"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=6579"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=6579"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=6579"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}