List:General Discussion« Previous MessageNext Message »
From:Gerald Clark Date:August 14 2001 6:16pm
Subject:Re: Lost bin-log(s) following logrotate affecting recovery,
replication
View as plain text  
I don't recall ever losing a log.
Are you sure logrotate isn't renaming it?

Joel Fowler wrote:

> I agree that Red Hat has an issue with safe_mysqld and logrotate.
> However, in my opinion MySQL has a much more serious problem.
> In a logging system there shouldn't be any subtle ways to drop records 
> let alone entire logs.
> Kill -HUP <mysqld.pid> is exactly that -- a very poor design leading to 
> a big trap - one which Red Hat just happened to fall in.
> 
> Joel Fowler
> ============================================
> At 08:36 AM 8/14/01 -0500, Gerald Clark wrote:
> 
>> This really is not a MySQL issue, but a Red Hat issue.
>> Don't logrotate the MySQL bin logs.
>> 
>> Joel Fowler wrote:
>> 
>>> Environment: Red Hat 7.1
>>>                     mysqld 3.23.36-log
>>> /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
>>> /etc/logrotate.d/mysqld (as distributed) follows:
>>> =================================
>>> /var/log/mysqld.log {
>>>     missingok
>>>     create 0640 mysql mysql
>>>     prerotate
>>>         [ -e /var/lock/subsys/mysqld ] && \
>>>         /bin/kill -HUP `/bin/cat /var/run/mysqld/mysqld.pid` || 
>>> /bin/true
>>>     endscript
>>>     postrotate
>>>         [ -e /var/lock/subsys/mysqld ] && \
>>>         /bin/kill -HUP `/bin/cat /var/run/mysqld/mysqld.pid` || 
>>> /bin/true
>>>     endscript
>>> }
>>> Problem Synopsis:
>>> ==============
>>> 1. /etc/logrotate.d/mysql executes a "kill -HUP <mysqld.pid>" during 
>>> pre and postrotate operations.
>>> 2. -HUP causes mysqld to discard all existing bin-logs (DISASTER) and 
>>> start a new one.
>>> 3. This destroys recovery strategies built on bin-logs.
>>>     It also (as far as I can tell) will cause replication to loose 
>>> logs and integrity.
>>> Note: This is a pretty big hole !!!
>>> To Simulate:
>>> =========
>>> 1. Configure bin-log(s)
>>> 2. List bin-log(s)
>>> 3. kill -HUP <mysqld.pid>
>>> 4. Bin-log(s) from 2. will have been purged and a new log started (as 
>>> if "reset master" was performed).
>>>    Note: For recovery and replication to work correctly existing 
>>> bin-log(s) must be left in tact.
>>> Any help will be appreciated.
>>> Please advise,
>>> Joel Fowler
>>> 
>>> ---------------------------------------------------------------------
>>> Before posting, please check:
>>>   http://www.mysql.com/manual.php   (the manual)
>>>   http://lists.mysql.com/           (the list archive)
>>> To request this thread, e-mail <mysql-thread82467@stripped>
>>> To unsubscribe, e-mail 
>>> <mysql-unsubscribe-gerald_clark=suppliersystems.com@stripped>
>>> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>> 
>> 
>> 
>> -- 
>> Gerald L. Clark
>> gerald_clark@stripped


-- 
Gerald L. Clark
gerald_clark@stripped

Thread
Lost bin-log(s) following logrotate affecting recovery,replicationJoel Fowler14 Aug
  • Re: Lost bin-log(s) following logrotate affecting recovery,replicationGerald Clark14 Aug
    • Re: Lost bin-log(s) following logrotate affecting recovery,replicationJoel Fowler14 Aug
  • Re: Lost bin-log(s) following logrotate affecting recovery,replicationGerald Clark14 Aug
    • Re: Lost bin-log(s) following logrotate affecting recovery,replicationJoel Fowler14 Aug
    • Re: Lost bin-log(s) following logrotate affecting recovery,replicationJoel Fowler14 Aug
      • Re: Lost bin-log(s) following logrotate affecting recovery, replication(Trond Eivind Glomsrød)14 Aug