Came after discussion with one of our important support customers (contact Guilhem Bichot for the name). We currently feature START SLAVE UNTIL [coordinates] where slave SQL thread will stop when it is at or beyond the coordinates. If slave SQL thread is already started, a warning is issued and nothing is done (slave SQL thread is not stopped even if it's at or beyond the coordinates). This command can be used to do master/slave synchronization, but the stop which occurs is sometimes undesirable (especially if there are automated scripts monitoring that the slave SQL thread is running, those scripts would send superfluous alarms - the is the case of our customer). The idea would be to: 1) add clauses AND STOP and AND BLOCK to START SLAVE UNTIL. AND STOP would be noise. AND BLOCK would not cause the slave SQL thread to stop but rather to suspend execution of replication events as soon as it is at or beyond coordinates: the slave SQL thread would be reported as "running", but would be sleeping. Disconnection of the session which issued the START SLAVE command, or issuing a START SLAVE in the same session, would unblock the slave SQL thread. Note that if a 2nd thread issues START SLAVE AND BLOCK while the first has blocked slave, the slave should not be unblocked: slave should unblock only when first thread decides to unblock, and then the request of the 2nd thread will be processed; until then, that request will hang (indicated by customer); like a mutex lock. 2) change the behaviour so that UNTIL (and AND STOP|BLOCK) is applied even if the slave SQL thread is already started. For consistency. ALTERNATIVE IMPLEMENTATION -------------------------- Lars thinks that it would be better to change the monitoring software to check *why* the slave has stopped, and possibly extend the slave reporting mechanism for this.