| Bug #74651 | mysql-community rpms uninstall followed by reinstall changes /etc/my.cnf | ||
|---|---|---|---|
| Submitted: | 31 Oct 2014 15:19 | Modified: | 5 Nov 2014 9:12 |
| Reporter: | Simon Mudd (OCA) | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Packaging | Severity: | S3 (Non-critical) |
| Version: | 5.6/5.7 | OS: | Linux (CentOS 6) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | community rpms, rpm, yum | ||
[31 Oct 2014 21:13]
Terje Røsten
Hi Simon, thanks for you report. To ensure our new rpm works out of the box with default MySQL 5.6 options we have to ship a /etc/my.cnf, for example we want to push: sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES as standard in MYSQL 5.6 as an config option, ref[1]. This means we can't ship the file as %ghost as with MySQL rpms. The file is marked as config file, this means we don't overwrite the file if present on install and save the file to .rpmsave (if modified) on uninstall. This is standard rpm behaviour and what most users expect. This is also safe as it don't deletes any information from the system. Having /etc/my.cnf or /etc/mysql/my.cnf as a file as part of MySQL server package seems to be very common. One of the goals of the yum repo and rpm packaging is to be more standard compliant. With our repos we try to cover use cases most of our users wants, it's not possible to cover everything or satisfy everyone. We also provide source rpms, use for example this to download: yumdownloader --source mysql-community-server so expert users can rebuild to fit their needs better. Specs files and related files are also available in source trees in sub dirs here: https://github.com/mysql/mysql-server/tree/5.7/packaging [1]: http://dev.mysql.com/doc/refman/5.6/en/mysql-install-db.html
[1 Nov 2014 21:40]
Simon Mudd
Thanks for your explanation. My main point is the older rpms that MySQL, Sun and now Oracle have been producing and which I guess are still used by quite a lot of people have different behaviour. They have been around for at least 7 years. You introduced new rpms using a yum repository (that idea is good) just one year ago, but have also introduced a large number of changes in the way the packages work. There's been little clear public comment I'm aware of that the old style rpms are going away, nor why the changes have happened. That would be helpful so a wider audience is aware of these changes and their implications. Since 5.7.5 the development 5.7 rpms are only produced in the new format, so to evaluate them I need to take these changes into account when setting them up on my systems. Some of these changes are quite a nuisance and I've opened other tickets about this. Going forward we must move to use these rpms if the older style won't be supported. I would not mind if all the changes did not have quite as many issues as I have seen. For a small user these details probably do not matter, but when several systems are managed some of the changes that have been made are quite troublesome. This specific issue is one of them, though perhaps one of the easiest to work around. I am aware of how to download the source rpms and I have compared the way they are built as I have had to apply custom patches in the past. I have also built my own rpms for other software in the past. However, going down the path of building my own rpms involves an amount of continued extra work and testing which is something I would rather avoid. I guess I will have to find out how others manage their installations in such a way that these are not issues for them and learn from them.
[5 Nov 2014 9:12]
Umesh Shastry
Hello Simon, Thank you for the report and feedback. Thanks, Umesh
[20 May 2016 8:31]
Terje Røsten
Hi Simon, it's hard to see an other fix than documenting change in behaviour. What do you think about this issue, now when you have used 5.7 rpms for a while?
Description: MySQL-server vs the community yum mysql-community-server rpms behave differently when uninstalling and installing a server package. With the new yum community packages the /etc/my.cnf file gets moved out of the way and thus replaced with a default config in the community packages. When doing an upgrade from one version to another this behaviour is most unhelpful and extra actions are needed compared to the MySQL-server packages which deliberately do not touch /etc/my.cnf. How to repeat: MySQL-server packaging: /etc/my.cnf survives package removal and reinstallation untouched ----------------------------------------------------------------------------------------- [root@server1 ~]# /etc/init.d/mysql status MySQL running (6604) [ OK ] [root@server1 ~]# mysql -e 'SHOW SLAVE STATUS\G' | grep Running Slave_IO_Running: Yes Slave_SQL_Running: Yes Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it [root@server1 ~]# head -2 /etc/my.cnf # my.cnf generated for version: 5.6.17 ########################################################################### [root@server1 ~]# /etc/init.d/mysql stop Shutting down MySQL.... [ OK ] [root@server1 ~]# rpm -q MySQL-server MySQL-server-5.6.17-1.el6.x86_64 [root@server1 ~]# rpm -e MySQL-server warning: /etc/logrotate.d/mysql saved as /etc/logrotate.d/mysql.rpmsave [root@server1 ~]# head -2 /etc/my.cnf # my.cnf generated for version: 5.6.17 ########################################################################### [root@server1 ~]# yum install -y MySQL-server Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile ... Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package MySQL-server.x86_64 0:5.6.17-1.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================================ Package Arch Version Repository Size ============================================================================================================================================================ Installing: MySQL-server x86_64 5.6.17-1.el6 xxxxxxxxxxxx 52 M Transaction Summary ============================================================================================================================================================ Install 1 Package(s) Total download size: 52 M Installed size: 233 M Downloading Packages: MySQL-server-5.6.17-1.el6.x86_64.rpm | 52 MB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Warning: RPMDB altered outside of yum. Installing : MySQL-server-5.6.17-1.el6.x86_64 1/1 Verifying : MySQL-server-5.6.17-1.el6.x86_64 1/1 Installed: MySQL-server.x86_64 0:5.6.17-1.el6 Complete! [root@server1 ~]# head -2 /etc/my.cnf # my.cnf generated for version: 5.6.17 ########################################################################### [root@server1 ~]# /etc/init.d/mysql start Starting MySQL.... [ OK ] [root@server1 ~]# mysql -e 'SHOW SLAVE STATUS\G' | grep Running Slave_IO_Running: Yes Slave_SQL_Running: Yes Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it [root@server1 ~]# mysql-community-server packaging: /etc/my.cnf does not survive package removal and reinstallation ------------------------------------------------------------------------------------------------- [root@server2 ~]# /etc/init.d/mysqld status mysqld (pid 19826) is running... [root@server2 ~]# /etc/init.d/mysqld restart Stopping mysqld: [ OK ] Starting mysqld: [ OK ] [root@server2 ~]# head -2 /etc/my.cnf # my.cnf generated for version: 5.7.5 ########################################################################### [root@server2 ~]# mysql -e 'SHOW SLAVE STATUS\G' | grep Running Slave_IO_Running: Yes Slave_SQL_Running: Yes Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates [root@server2 ~]# /etc/init.d/mysqld stop Stopping mysqld: [ OK ] [root@server2 ~]# rpm -q mysql-community-server mysql-community-server-5.7.5-0.6.m15.el6.x86_64 [root@server2 ~]# rpm -e mysql-community-server warning: /etc/my.cnf saved as /etc/my.cnf.rpmsave <<==== moved out of the way here warning: /etc/logrotate.d/mysql saved as /etc/logrotate.d/mysql.rpmsave [root@server2 ~]# yum install -y mysql-community-server Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile ... Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package mysql-community-server.x86_64 0:5.7.5-0.6.m15.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================================ Package Arch Version Repository Size ============================================================================================================================================================ Installing: mysql-community-server x86_64 5.7.5-0.6.m15.el6 xxxxxxxxxxxxx 79 M Transaction Summary ============================================================================================================================================================ Install 1 Package(s) Total download size: 79 M Installed size: 358 M Downloading Packages: mysql-community-server-5.7.5-0.6.m15.el6.x86_64.rpm | 79 MB 00:01 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Warning: RPMDB altered outside of yum. Installing : mysql-community-server-5.7.5-0.6.m15.el6.x86_64 1/1 Verifying : mysql-community-server-5.7.5-0.6.m15.el6.x86_64 1/1 Installed: mysql-community-server.x86_64 0:5.7.5-0.6.m15.el6 Complete! [root@server2 ~]# head -2 /etc/my.cnf # For advice on how to change settings please see # http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html [root@server2 ~]# This is the default installation. Cause is likely to be related to spec file: In the origin MySQL-server rpms: %ghost %config(noreplace,missingok) %{_sysconfdir}/my.cnf vs the following in the new rpms: %config(noreplace) %{_sysconfdir}/my.cnf Suggested fix: Please do not move the /etc/my.cnf file out of the way or touch it at all when uninstalling the rpm. You do not know what the DBA may intend to do next. If it's not to remove MySQL completely then it may be to upgrade it and moving the my.cnf file out of the way means that an extra step is needed. This was not necessary before and the configuration had been deliberately setup to prevent this sort of behaviour. So please look at the packaging configuration and if there's a non-standard /etc/my.cnf file do not touch it _ever_.