<p>MySQL raises Error 1721 (ER_PLUGIN_NO_INSTALL) when you attempt to load a plugin that the server marks as not dynamically installable; the server must be shut down and restarted with the plugin statically configured.</p>
<p>MySQL Error 1721 ER_PLUGIN_NO_INSTALL appears when you run INSTALL PLUGIN for a component flagged as non-dynamic. Stop the MySQL server, add the plugin to the my.cnf plugin-load list, then restart the service to resolve the issue.</p>
Plugin '%s' is marked as not dynamically installable. You
Error 1721 fires with SQLSTATE HY000 and message “Plugin '%s' is marked as not dynamically installable. You have to stop the server to install it.” It occurs when INSTALL PLUGIN or INSTALL COMPONENT tries to load a module whose source code or manifest declares itself static only.
MySQL blocks runtime installation for safety because the plugin may alter core subsystems that require initialization at startup. Understanding this safeguard helps you pick the right installation method and maintain server stability.
The server checks the plugin header during INSTALL PLUGIN. If the plugin_info struct contains the flag PLUGIN_OPT_NO_INSTALL, MySQL immediately aborts and returns 1721. The same happens for components compiled without COMPONENT_INSTALL_IF_DYNAMIC.
You will mostly see the error after upgrading to a version where the plugin policy changed, migrating third-party binaries, or enabling enterprise extensions on community builds.
Leaving required plugins unloaded prevents features like authentication, audit or storage engines from working. Repeated failed INSTALL attempts clutter logs and can trigger monitoring alerts. Resolving the error quickly restores desired functionality and keeps automated deployments green.
The primary cause is attempting dynamic installation of a plugin compiled as static-only. Secondary causes include mismatched MySQL versions, missing OS libraries forcing the plugin loader to misclassify the module, or insufficient privileges that mislead admins into repeated INSTALL attempts.
Stop the MySQL service, edit my.cnf (or my.ini) to include the plugin in plugin-load-add, then restart the server. The plugin will initialize during startup, bypassing the dynamic restriction.
On Linux systemd servers, use systemctl stop mysqld, modify /etc/my.cnf, and systemctl start mysqld. In Docker, rebuild the image with the plugin copied to /usr/lib/mysql/plugin and add the --plugin-load parameter in the container command.
Always read plugin documentation for installation flags, bundle static-only plugins in base images, automate configuration management, and test plugin loads in staging.
Using Galaxy’s connection templates, you can preload required plugin parameters in the editor’s connection string, ensuring teammates never attempt runtime INSTALL PLUGIN commands that would trigger Error 1721.
The plugin developer compiled the module with PLUGIN_OPT_NO_INSTALL, blocking dynamic loading.
The plugin was built for an earlier or later MySQL version, and the server refuses to install it dynamically.
Required shared libraries are absent, leading the loader to mark the plugin non-dynamic.
Running INSTALL PLUGIN without SUPER or SYSTEM_VARIABLES_ADMIN may surface the error indirectly.
Occurs when MySQL cannot find or load a plugin's .so file. Unlike 1721, the plugin is dynamic but missing.
Indicates packet size limits, unrelated to plugins but often seen during misconfigured installations.
Appears when authentication plugins fail to load, sometimes a downstream effect of 1721.
No. The static flag is hard-coded. You must restart the server after adding the plugin to my.cnf.
Usually not. It simply means the plugin was compiled for startup loading only.
Only if the plugin provider also ships a dynamically loadable version for the new release. Otherwise the restriction remains.
Galaxy surfaces server errors instantly in its results pane and lets teams share fixed connection configs, reducing repeated 1721 incidents.