No, unfortunately they just seem to be gone along with the integrity of
most good recovery strategies.
Joel Fowler
======================================
At 01:16 PM 8/14/01 -0500, Gerald Clark wrote:
>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 <[EMAIL PROTECTED]>
>>>>To unsubscribe, e-mail
>>>><[EMAIL PROTECTED]>
>>>>Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>>>
>>>-- Gerald L. Clark
>>>[EMAIL PROTECTED]
>
>
>--
>Gerald L. Clark
>[EMAIL PROTECTED]
---------------------------------------------------------------------
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 <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
