I’ve found some issues upgrading mysql, some people recommends run mysql_upgrade. I wonder why such a script is not run from scriptlet of mysql-server rpm.
Thanks in advance
> Good. Now you’re starting to think like a packager Avoiding MUD is
> *much* more important than attempting magic.
> The bottom line is you shouldn’t attempt a database conversion as
> part of the package install. The package, however, should contain programs
> and procedures necessary to do the job.
Lamar Owen wrote:
We have an answer we really like: yum-post-transaction-actions. Great plugin… and it will do whatever you want… like, say: sed -i s/sbin\/shutdown/bin\/false/ /etc/apcupsd/apccontrol
mark “and are there three, or six, servers plugged ino the rackmount
The real reason something like mysql_upgrade isn’t run automatically hasn’t really much to do with the technicalities of RPM but the fact that mysql_upgrade might kill your server if you don’t know what you are doing. If for example you have a big table that takes up 70% of your storage and mysql_upgrade needs to convert it to a new format then it will create a copy of that table in the new format first and then delete the old one…except of course that this would require 140% of disk space to work.
So independent of the packaging technology used major changes like these should never be done automatically and instead always be handled by an admin who knows what he is doing.
Really convincing answers!
2016-04-28 13:53 GMT-03:00 Dennis Jacobfeuerborn :
pi.o < http://www.lpi.org>rg < http://www.lpi.org>
The general SOP is to restart mysql, then run mysql_upgrade, so the RPM
script would need to do both. This brings you into database and application management territory, and out of package management territory. The RPM cannot know if it is acceptable and safe for the database to go down, for both your environment and organization. Accordingly, as a rule, RPMs should not affect running services.
Ubuntu/Debian packages *do* perform these actions on package update, and I’ve seen it go horribly wrong. Like, the restart command hangs because of long running queries, and the tablespace changes happen anyway, leaving the daemon in a state where it cannot accept new connections because it was shutting down, but cannot cleanly shut down because of the other actions in the script. You really want an admin to do this work, not an unattended script.