Request from big customer. Quoting his reasons: > 1) As far as I understand, if the slave is behind and you execute CHANGE > MASTER on the slave, the slave will delete its relay logs and start > replicating from the new position. It would be very useful if CHANGE > MASTER would only repoint the IO thread, while the SQL thread continued to > execute its relay logs. Here is why it's useful. Suppose you have a master > and 20 slaves, where all slaves are several hours behind. If the master > were to go down and we wanted to repoint all slaves to another master, we > would have to wait until SQL thread caught up everywhere; only then would > it be safe to execute CHANGE MASTER TO. It would be nice to CHANGE MASTER > as soon as we know that the IO thread is caught up. The slaves would > continue to execute the relay logs from the old master, then start > executing statements on the new msater. So simply it means when CHANGE MASTER happens, don't delete relay logs, just start using a new one. So that the slave SQL thread can finish executing the old logs while the I/O thread fetches the new ones. Proposed implementation: in MySQL 4.1 I have already introduced a global variable SET GLOBAL RELAY_LOG_PURGE= 0 or 1 (default is 1) I could do this, starting from 4.1 : - if RELAY_LOG_PURGE == 1, CHANGE MASTER will behave like now (purge relay logs) - if RELAY_LOG_PURGE == 0, CHANGE MASTER will keep relay logs The only complicated thing is that the CHANGE MASTER code is a bit strange and so changing things into it might trigger unexpected bugs; the task in itself is changing a few lines, but there is testing/debugging after that.