Comment 2 for bug 1239670

master_auto_position relies on GTIDs to know what transactions have been applied and what transactions have not, so they are essential to be able to actually use a cloned slave to replicate. GTIDs are a replacement for binlog and position, which spells out which transactions have been applied. Thus, MySQL knows that it does not need to apply those transactions, but will apply everything else not in the purge list.

So here's an example:

master -> slave1

If you want to spin up slave2, but don't want to take up resources on the master, you would run innobackupex --slave-info against slave1, and restore to slave2. However, without the GTID information, slave2 would try to reapply ALL the transactions in the master's binary logs, because there is nothing in the purge list. This will cause duplicate key errors and duplicate data when there are no unique keys on data.

In summary - think of it as like not having binlog information - you have a good clone, but you can't easily figure out where to start replication from.