From the documentation...
CHANGE MASTER TO deletes all relay log files and starts a new one, unless you specify
RELAY_LOG_POS. In that case, relay log files are kept; the relay_log_purge global variable is set silently to 0.
SHOW SLAVE STATUS will give you the current
Relay_Log_Pos even if the slave is stopped... so after looking up those values:
CHANGE MASTER TO MASTER_DELAY = 0, RELAY_LOG_FILE = 'xxxxx-relay-bin.######', RELAY_LOG_POS = ######;
Since delayed replication only delays playback from the relay log -- not the receiving of events from the master -- your relay log should have everything up until "now" (or whenever the master was actually lost), so this should bring your slave current.
One thing, though...
relay_log_purge global variable is set silently to 0.
I'm not so sure about this behavior. I tested the above on 5.6.10 the variable did not change from 1 to 0. Also, there's no mention of this in the changelogs for 5.6.11 or 5.6.12. You may want to check this global variable before and after you issue the
CHANGE MASTER TO and re-set it to
ON if it does actually toggle.
Update: the source code, in
sql/rpl_slave.cc, clarifies the confusion in the documentation.
It preserves the value of the global variable
my_bool save_relay_log_purge= relay_log_purge;
If either of these conditions are met...
relay_log_purge is set to 0 until the
CHANGE MASTER TO is finished, at which point it gets set back to its previous value.
So the global varible is silently set to 0, but then gets set back again to whatever it was before.