Nope, we use the expire_logs_days parameter in MySQL's my.cnf (set to
expire_logs_days=7 - removes log files that are 7 days old.)
mysqldump's flush-logs does indeed begin a new log - that's the idea of it:
# ls -l /srv/mysql
rw-rw---- 1 mysql localservice 213 2008-10-16 00:56 sql-m2-bin.000017
-rw-rw---- 1 mysql localservice 213 2008-10-17 00:56 sql-m2-bin.000018
-rw-rw---- 1 mysql localservice 213 2008-10-18 00:56 sql-m2-bin.000019
-rw-rw---- 1 mysql localservice 213 2008-10-19 00:56 sql-m2-bin.000020
-rw-rw---- 1 mysql localservice 213 2008-10-20 00:56 sql-m2-bin.000021
-rw-rw---- 1 mysql localservice 213 2008-10-21 00:56 sql-m2-bin.000022
-rw-rw---- 1 mysql localservice 213 2008-10-22 00:56 sql-m2-bin.000023
-rw-rw---- 1 mysql localservice 213 2008-10-23 00:56 sql-m2-bin.000024
-rw-rw---- 1 mysql localservice 98 2008-10-23 00:56 sql-m2-bin.000025
# /usr/local/mysql/bin/mysqldump --single-transaction --flush-logs
--master-data=2 --all-databases --user=xxx --password=xxx >
/tmp/backup_2008-10-23.sql
# ls -l /srv/mysql
-rw-rw---- 1 mysql localservice 213 2008-10-17 00:56 sql-m2-bin.000018
-rw-rw---- 1 mysql localservice 213 2008-10-18 00:56 sql-m2-bin.000019
-rw-rw---- 1 mysql localservice 213 2008-10-19 00:56 sql-m2-bin.000020
-rw-rw---- 1 mysql localservice 213 2008-10-20 00:56 sql-m2-bin.000021
-rw-rw---- 1 mysql localservice 213 2008-10-21 00:56 sql-m2-bin.000022
-rw-rw---- 1 mysql localservice 213 2008-10-22 00:56 sql-m2-bin.000023
-rw-rw---- 1 mysql localservice 213 2008-10-23 00:56 sql-m2-bin.000024
-rw-rw---- 1 mysql localservice 213 2008-10-23 19:37 sql-m2-bin.000025
-rw-rw---- 1 mysql localservice 98 2008-10-23 19:37 sql-m2-bin.000026
Notice the last write time of sql-m2-bin.000025 and the new file
sql-m2-bin.000026. Note this was on my slave server which was why the
logs never get written to past 00:56 each morning! Also my backup
script substitutes the date as appropriate into the dump file.
Regards,
Andy
Olaf Stein wrote:
And I assume you backup script also archives or removes the old log file,
because flush-logs does not start a new log file if there is still one
present
On 10/23/08 2:20 PM, "Andy Shellam" <[EMAIL PROTECTED]> wrote:
Hi Olaf,
We use our mysqldump script to rotate the binlogs; it's much safer as it
allows MySQL to do the log rotate natively (if you use logrotate, MySQL
will complain that either the log doesn't exist when it expects it to,
or your slaves will bail out because they didn't know the log was
changed. It happened to us recently when we moved the log directory and
didn't update the log index.)
At 2am our backup system runs the mysqldump script with the extra
parameter --flush-logs. This causes MySQL to rotate the log it's using,
and as you found out, all slaves respond to the change without an issue.
Andy
Olaf Stein wrote:
Thanks all...
Rotating actually does not affect the slaves, they adjust to the new binlog
just fine, I guess I should have tried that first.
I will nevertheless take a closer look at logrotate...
Olaf
On 10/23/08 12:13 PM, "Uwe Kiewel" <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Olaf Stein schrieb:
Hi all
Is it possible to rotate just the regular (--log) log file?
I am not sure if it will be safe, but maybe with logrotate and for
/var/log/mysqld.log the "copytruncate" option for logrotate.
If I do flush-logs I have to tell my slaves that (at least I have done so
in
the past, maybe I don't and the slves realizes by itself?)
I think so, b/c I've never told my slaves...
HTH,
Uwe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBAgAGBQJJAKK3AAoJEEJXG7BUuynntkkP/R5IiZWpafUfQqR+hVUax9at
NV8YKfUIz8J1QLrT7cWOEqpuliABP0P6AOS06Tmm4t2ve15BJ1fwxRqHiHEem9BE
7nb1AuQDlGW+qTOVpzJqj2H8b5SARdLoKswTisT0Yz++NDj3WQxVM/UIKotwRnLH
edDHSrfjPl+38TmlmGP7/3ZYA2gEAKosgYGrax6bHtSnrw2pfDq6BaXvEwXABAHc
aCE6P3DKGr4Ycs2Xlc49IkPHgE6/+SNM9MqVAs83OgxNZK5+c474YdJl7i5hfth1
8RKMPweQgBtYRT3vfrvJdfzg2Wg75pJv1RwkKiGofaAjBmO9y93iNkE57pNXq3sd
eWFZR5YcPA+3+GCnAvOMcjzytISlpxNNic235qaYSuoNDMV1rukxSYNpH62kzQPH
V3gTKuZcjWYWasa0Y6ylSBWywSOnfc49n0mVdXeoHb7CpIQn3jwCtRG2+UCZUM1W
O4U5+bKgXERqqwjNS5sk9SNmq5gQAKYU4IsDZwZcyFY7t/XEHwB3+bCVnm1y4V/s
Fzin0FoAIbqm9VzALzTs5YUkWzoSzniGepIBrZR0PO98sDxOlDFUESpYnFj8oNap
wjM/5P0tgbw99lIsLAMy7+FdPIlSssWxq+LFC4dR6o+pzVrYjFjoRg3MdYn9ein8
svOEP/N79cK5pPZJpDyY
=cN1H
-----END PGP SIGNATURE-----
----------------------------------------- Confidentiality Notice:
The following mail message, including any attachments, is for the
sole use of the intended recipient(s) and may contain confidential
and privileged information. The recipient is responsible to
maintain the confidentiality of this information and to use the
information only for authorized purposes. If you are not the
intended recipient (or authorized to receive information for the
intended recipient), you are hereby notified that any review, use,
disclosure, distribution, copying, printing, or action taken in
reliance on the contents of this e-mail is strictly prohibited. If
you have received this communication in error, please notify us
immediately by reply e-mail and destroy all copies of the original
message. Thank you.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
