Comment 2 for bug 1372679

Exec_Master_Log_Pos indeed cannot be trusted with slave_parallel_workers > 0. Currently no backup utilities warn users about this fact (I have checked mysqldump, mydumper and mylvmbackup).

The only available option to clone a multi-threaded slave seems to be using GTID (though I could not find any confirmation in the MySQL manual).

I'm not sure about the suggested workaround. Does setting slave_parallel_workers to 0 and then resetting the slave guarantee that Exec_Master_Log_Pos will correspond to the most recently executed transaction? The manual says the following:

"START SLAVE UNTIL SQL_AFTER_MTS_GAPS should be used before switching the slave from multi-threaded mode to single-threaded mode (that is, when resetting slave_parallel_workers back to 0 from a positive, nonzero value) after slave has failed with errors in multi-threaded mode. "

If the slave is GTID-enabled, write_slave_info() will automatically write "SET GLOBAL gtid_purged=...; CHANGE MASTER TO MASTER_AUTO_POSITION=1" to xtrabackup_slave_info, i.e. Exec_Master_Log_Pos will not be used.

I'm going to add a check to innobackupex so that if slave_parallel_works is non-zero and GTID is not enabled, the --slave-info option would fail with a descriptive error.