I’ve tried that and it worked fine.

As per your suggestion to try relay-log.info file: couldn’t do that because of ‘relay_log_info_repository=TABLE’.

Also try asking on dba.stackexchange.com

But do try following on the last paragraph in said documentation:

” The relay-log.info file now contains the delay value, so the file format has changed. See Section 16.2.2.2, “Slave Status Logs”. In particular, the first line of the file now indicates how many lines are in the file. If you downgrade a slave server to a version older than MySQL 5.6, the older server will not read the file correctly. To address this, modify the file in a text editor to delete the initial line containing the number of lines. “

This isn’t correct – as per my test.
After the commands:
stop slave;
CHANGE MASTER TO MASTER_DELAY=0;
start slave;
and while the Master is still not available – the IO slave is in “Connecting”State, all the existed before relay logs are deleted, and the SQL changes executed at the Master – were NOT applied at the Slave…

As per http://dev.mysql.com/doc/refman/5.6/en/replication-delayed.html,
just CHANGE MASTER TO MASTER_DELAY=0;
and the slave will just execute whatever it has got in the relay logs.

Scenario: Master-Slave replication in 5.6 with a Delay (let’s say 2 hours). The Master fails and isn’t available at all.
The question is : what is the proper way to cause the Slave to execute all the not-yet-applied SQL ?(i.e. to cause SQL_Remaining_Delay to become 0 , without waiting the 2 hours ?)

Thank you for elaborating. 5.6 presents undo log on its own tablespace. Is this a development change that can allow multiple tablespaces, then?

The data dictionary is located in the system table space (if there are multiple ibdata files, it might even be spread about those).

Now if you remove an ibd file without touching the DD, then InnoDB will sometimes just refuse to do anything (including deleting the table from the DD) with “table does not exist” error. If you happen to delete the ibd file for a single partition of a partitioned table, then InnoDB might even crash.

OTOH you could just delete the shared table space(s) (and thus also the DD) – then InnoDB will forget anything it ever knew about any InnoDB table. Any data in ibd files will be lost (not quite, it is possible to recover such data, but not automatically)

OK. Nothing of this is new.

Now what is bad with the new InnoDB system tables in 5.6 is that the server cannot recover from losing them. OTOH InnoDB can perfectly well recover from losing the DD – it will just create a new, empty one. And exactly the same it should do for the statistics and slave status tables. OK, this is a bit harder because those tables can use file_per_table. And they do have frm files. Maybe this was wrong in the first place. I don’t see why those tables could not be anonymous system tables just as the DD.