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
