Terry Riley wrote:
I'm running 4.1.13 on Linux as master, with 4.1.12 on XP as slave (in
house test setup).
This vaguely duplicates what is set up on the live servers, except that
the slave is 4.1.3 on NT4.
On the test setup, if the logs are flushed on the master, the bin log is
rotated to the next number, after closing (and preserving) the old one. On
the slave, the change to the master bin-log is duly recognised in the
slave status output.
If I issue 'flush logs' on the slave, however, the old
[servername]-relay-bin.0000nn file is closed, the n+1 is opened, and the
original is deleted completely.
My only reason for wishing to rotate logs this way is to prevent files
getting too large to handle effectively in the event of needing to
reinstate (either the master or the slave). However, the way that log
flush on the slave seems to work implies that a backup of it should be
taken before flushing, or you won't ever see that logged data again.
Is this the way it is meant to be? I don't want to institute any log
rotation policy on the slave of the live setup if this happens.....
Regards
Terry Riley
see http://dev.mysql.com/doc/mysql/en/slave-logs.html
Basically, the master's binary log and the slave's relay log, though the
same format, serve different purposes. The slave's relay log is a
short-term copy of as much of the master's binary log as the slave's IO
thread has read; this relay log is what the slave's SQL thread
processes. This file is not needed once it is read since it does not
store anything that is not stored in the master's binary log, and this
file is not used for replication from the slave to another server.
If your slave is handling updates, it should be writing a binary log so
you can replicate those updates back to the master.
Best regards,
Devananda vdv
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
