Re: Flushing logs on replication setup
- Original Message - 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.nn 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 Thanks, Devananda! I really should have looked at the manual once again. I'm not sure what you meant by the last sentence - all the updates are done on the master, and they are naturally replicated to the slave. Did you mean 'handling DIRECT updates'? I turned on the binlog for the slave, then made some updates on the master, and nothing changed in the slave bin log, only the relay log. That is normal, yes? Cheers Terry -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Flushing logs on replication setup
Terry Riley wrote: - Original Message - 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.nn 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 Thanks, Devananda! I really should have looked at the manual once again. I'm not sure what you meant by the last sentence - all the updates are done on the master, and they are naturally replicated to the slave. Did you mean 'handling DIRECT updates'? I turned on the binlog for the slave, then made some updates on the master, and nothing changed in the slave bin log, only the relay log. That is normal, yes? Cheers Terry Yes, that is normal. What I meant is that, IF you modify data directly on the slave, it will need binary logging enabled if you want those updates to replicate to the master. The relay log only stores information from the master's binary log for the slave to process. (FYI, I try to have all of my companies' servers running with bidirectional replication, ie A-B and B-A, just in case we need to fail over to the slave at any time. This makes it easier to bring the master back up to date afterwards.) Regards, Devananda vdv -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Flushing logs on replication setup
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.nn 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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Flushing logs on replication setup
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.nn 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]
