Windows specific functionality "mysqld --install" , "mysqld --remove" should not be used anymore. This functionality is deprecated since we have mysql_install_db.exe, i.e 5.5. mysql_install_db.exe does the service registration and more.
Removing a service is a simple call to "sc delete <service_name>".
Also the logic "if mysqld.exe was started without parameters, lookup for MySQL service name and start it, if exists", this should be removed.
I meant, reading "Chris' blog post" attentively . this blog post has not changed since 2012. It describes the very same problem you just had, gives an explanation, why binpath should add the servicename at the end.
Also note you can't always switch versions by simply restarting with new executables. if you upgrade from 10.4 to 10.5 for example, you need to stop the server with "innodb slow shutdown" (--innodb-fast-shutdown=0), and you likely need to run
mysql_upgrade after major version switch for system tables upgrade.
And mysql_upgrade_service takes care of all that, given that executables for the new version are in a different path. and of course, it also takes care of changing service's binPath.
Vladislav Vaintroub
added a comment - - edited I meant, reading "Chris' blog post" attentively . this blog post has not changed since 2012. It describes the very same problem you just had, gives an explanation, why binpath should add the servicename at the end.
Also note you can't always switch versions by simply restarting with new executables. if you upgrade from 10.4 to 10.5 for example, you need to stop the server with "innodb slow shutdown" (--innodb-fast-shutdown=0), and you likely need to run
mysql_upgrade after major version switch for system tables upgrade.
And mysql_upgrade_service takes care of all that, given that executables for the new version are in a different path. and of course, it also takes care of changing service's binPath.
So, would it be correct to state that you were requesting that "mysqld --install" should continue to live, to manually / partially replicate the logic of mysql_upgrade_service? Why not just to use mysql_upgrade_service as-is?
Vladislav Vaintroub
added a comment - So, would it be correct to state that you were requesting that "mysqld --install" should continue to live, to manually / partially replicate the logic of mysql_upgrade_service? Why not just to use mysql_upgrade_service as-is?
> Why not just to use mysql_upgrade_service as-is?
Because:
E:\wamp64\bin\mariadb\mariadb10.4.13\bin>mysql_upgrade_service --service=wampmariadb64
FATAL ERROR: Not a valid MySQL service
E:\wamp64\bin\mariadb\mariadb10.5.4\bin>mysql_upgrade_service --service=wampmariadb64
FATAL ERROR: Not a valid MySQL service
While it works perfectly for more than fifteen years with mysqld.exe --install-manual and --remove for MariaDB from 5.5.62 to 10.5.4 and for MySQL from 5.1.72 to 8.0.20
Dominique Ottello
added a comment - - edited > Why not just to use mysql_upgrade_service as-is?
Because:
E:\wamp64\bin\mariadb\mariadb10.4.13\bin>mysql_upgrade_service --service=wampmariadb64
FATAL ERROR: Not a valid MySQL service
E:\wamp64\bin\mariadb\mariadb10.5.4\bin>mysql_upgrade_service --service=wampmariadb64
FATAL ERROR: Not a valid MySQL service
While it works perfectly for more than fifteen years with mysqld.exe --install-manual and --remove for MariaDB from 5.5.62 to 10.5.4 and for MySQL from 5.1.72 to 8.0.20
Your solution or upgrade just does not work, on the reason outlined above.
If you want to file a bug for mysql_upgrade_service, I might happily accept it. Or, you can try to replicate whatever mysql_upgrade_service is doing, poorly
Vladislav Vaintroub
added a comment - Your solution or upgrade just does not work, on the reason outlined above.
If you want to file a bug for mysql_upgrade_service, I might happily accept it. Or, you can try to replicate whatever mysql_upgrade_service is doing, poorly
Task
Major
I meant, reading "Chris' blog post" attentively . this blog post has not changed since 2012. It describes the very same problem you just had, gives an explanation, why binpath should add the servicename at the end.
Also note you can't always switch versions by simply restarting with new executables. if you upgrade from 10.4 to 10.5 for example, you need to stop the server with "innodb slow shutdown" (--innodb-fast-shutdown=0), and you likely need to run
mysql_upgrade after major version switch for system tables upgrade.
And mysql_upgrade_service takes care of all that, given that executables for the new version are in a different path. and of course, it also takes care of changing service's binPath.