Bug 51711 - MySQL looses bin-logs during logrotate
Summary: MySQL looses bin-logs during logrotate
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mysql   
(Show other bugs)
Version: 7.1
Hardware: All Linux
high
high
Target Milestone: ---
Assignee: Patrick Macdonald
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-14 07:16 UTC by Joel Fowler
Modified: 2009-10-01 12:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-14 22:56:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Joel Fowler 2001-08-14 07:16:06 UTC
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

Comment 1 Trond Eivind Glomsrxd 2001-08-14 15:45:20 UTC
This fix will probably be in MySQL 3.23.42, which isn't released yet....

Comment 2 Joel Fowler 2001-08-14 18:12:15 UTC
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?

Comment 3 Trond Eivind Glomsrxd 2001-08-14 18:17:46 UTC
The logrotate script is changed in 3.23.41 to use the (looks new) "mysqladmin
flush-logs" directive.

Comment 4 Trond Eivind Glomsrxd 2001-08-14 19:06:20 UTC
That should be fixed in  mysql-3.23.41-1


Comment 5 Joel Fowler 2001-08-14 22:34:55 UTC
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?

Comment 6 Joel Fowler 2001-08-14 22:56:14 UTC
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?

Comment 7 Trond Eivind Glomsrxd 2001-08-26 20:24:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.