From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2smp i686; Nav) Description of problem: /etc/logrotate.d/mysql pre & post rotate executes kill -HUP <mysqld.pid>. This causes mysqld to discard (delete ~ "reset master") all current bin-logs. This destroys any ability to recover using these logs. It will also destroy ability the ability to do mysql replication. How reproducible: Always Steps to Reproduce: 1.Have bin-logs configured 2. Check bin-logs (ls -l <log-dir>; more <bin-log>.index) 3.Simulate logrotate by executing "kill -HUP <mysqld.pid> Actual Results: Earlier bin-logs disappeared as if a "reset master" had been performed. Expected Results: Earlier logs to remain for recovery and replication. Additional info: /etc/my.cnf as follows: [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock log-bin=/bu/mysql/online-log/iServ2 log-bin-index=/bu/mysql/online-log/iServ2.index [mysql.server] user=mysql basedir=/var/lib [safe_mysqld] err-log=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
This fix will probably be in MySQL 3.23.42, which isn't released yet....
What exactly is getting fixed in MySQL 3.23.42. In my opinion there are two defects. MySQL shouldn't do a "reset master" on a kill -HUP <mysql.pid>. The other defect is the /etc/logrotate.d/mysql script which exploits the MySQL problem by executing two "kill -HUP <mysql.pid>". Understanding the MySQL -HUP problem makes this script a "DISASTER" as it leads to "LOST INTEGRITY", something you can't tollerate from a database. Consequently, this script needs fixed "NOW" and not wait for some future MySQL change. Also, since logs are created as a redirection in safe_mysql I don't see how this script will ever work correctly. Please enlighten me?
The logrotate script is changed in 3.23.41 to use the (looks new) "mysqladmin flush-logs" directive.
That should be fixed in mysql-3.23.41-1
I've done some research and it appears that "kill -HUP <mysql.pid>" was changed in 3.23.40 to do a flush-logs vs. reset-master. There is a binary rpm for 3.23.41-1 that should include it. My question for you is this: I understand that Red Hat uses custom packaging for MySQL (i.e. different target directories)? Can I apply this MySQL 3.23.41-1 binary rpm on top of my Red Hat Linux 7.1 system and expect everything to work OK? Is any special upgrade procedure needed? Do I need to tweak the install in any way?
The mention of 3.23.42 was because a reporter said the fix would be in there. However, 3.23.41 should be sufficient. As for the question of 3.23.41 rpm - it may work, but I haven't tested. If not, do a "rpm --rebuild" of the src.rpm and install the result.