Re: Why do gaps/skips occur in GTID sets?

[Matt Lord]

The possible causes are:
1. You're not using master_auto_position=1 and thus positions, which happen to contain GTIDs, are getting skipped (sql_slave_skip_counter, changing file/position in CHANGE MASTER TO, etc.)
2. You're using master_auto_position=1 and purging binary logs on the master (mysql01) before the slave(s) (mysql02) have processed all GTIDs contained within them

You didn't say, but I'm guessing that you're seeing this error in the log and SHOW SLAVE STATUS output on mysql02 when it tries to setup replication from mysql01:
[ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

That indicates that the binary logs on mysql01 have been purged, and no longer contain the needed GTIDs (the ones in the gaps).

I don't know what you mean when you say "these GTIDs don't exist". Clearly they existed on mysql01 as they are in its gtid_executed set.

Based on what you've said, which isn't much :), I'm guessing that you'll see the GTIDs missing on mysql02 (in the gaps) in the gtid_purged set on msyql01:
mysql> select @@global.gtid_purged;

Which means that they've been executed on mysql01 but are no longer available in binary logs.

You definitely don't want to simply inject empty GTIDs for those on mysql02, as then the data has diverged from mysql01. I'm assuming that you want mysql01 and mysql02 to contain the same data set. If you've been doing this kind of thing then in the past then I would expect you to continue to run into more and more problems as the data sets diverge further and further.