Something that is not entirely clear about the mysql binary logs in the documentation is whether the mysql daemon itself begins to write logs with different names at different points in time, or if it simply writes to .001 and your logrotate daemon (perhaps as directed by mysql's bundled logrotate scripts) rotates out old files at intervals.
The reason that this is confusing to me is because we have two different almost congruent setups, and on one of them the mysql binary logs rotate by themselves (new logs get created at intervals, and all the logs are recorded in the binary log index file) and we can safely restart our master mysql daemon, but on the other setup the logs do not appear to rotate, and restarting the mysql master daemon causes all heck to break loose. The slaves begin trying to read from non-existant log files, and the master truncates the only log file it wants to write to (.001) and starts it over. All the mysql servers we have are version 3.23.36 running on Linux 7.1 kernel 2.4.5 and 2.4.12 (the ones that were rotating correctly were on kernel 2.4.12, but the newest available rpm was 2.4.5 and we're not authorized to run experimental kernels on our production machines). We have a replicate-ignore-wild-tables=mysql.* as our only relevant replication setting. So has anyone else ever seen this kind of problem before, or else could somebody shed some light on what mysql's dogma is so far as when and how it "rotates" it's binary logs? I'm familiar with how a bloke can "purge to" to delete older logs, but I'm interested in how the logs get seperated into different files in the first place. Thanks for listening :) - - Jesse Thompson bend.com --------------------------------------------------------------------- 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
