Bug 51711 - MySQL looses bin-logs during logrotate
MySQL looses bin-logs during logrotate
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: mysql (Show other bugs)
7.1
All Linux
high Severity high
: ---
: ---
Assigned To: Patrick Macdonald
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-14 03:16 EDT by Joel Fowler
Modified: 2009-10-01 08:05 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Joel Fowler 2001-08-14 03:16:06 EDT
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 11:45:20 EDT
This fix will probably be in MySQL 3.23.42, which isn't released yet....
Comment 2 Joel Fowler 2001-08-14 14:12:15 EDT
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 14:17:46 EDT
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 15:06:20 EDT
That should be fixed in  mysql-3.23.41-1
Comment 5 Joel Fowler 2001-08-14 18:34:55 EDT
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 18:56:14 EDT
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 16:24:14 EDT
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.