Comment 4 for bug 1522385

OK, it appears that not only skipped replication errors may cause dummy, empty trx on async slave, hence GTID hole on galera peers.

When a row in table with PK is updated first on slave, then same update is done on master, then the PK value to identify the row is still present on the slave, and no replication error happens. But as the other columns have already the same values, no real update happens, but only empty begin/commit. I made the below test without any slave_skip_errors setting.

 CREATE TABLE `g1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` char(10) DEFAULT 'test',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

--slave:
percona1 mysql> update g1 set a="aa" where id=3;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0

--master:
db1 {root} (test) > update g1 set a="aa" where id=3;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0

-- master's binlog:
| binlog.000009 | 689 | Gtid | 1 | 737 | SET @@SESSION.GTID_NEXT= '12446bf7-3219-11e5-9434-080027079e3d:7206' |
| binlog.000009 | 737 | Query | 1 | 809 | BEGIN |
| binlog.000009 | 809 | Table_map | 1 | 857 | table_id: 71 (test.g1) |
| binlog.000009 | 857 | Update_rows | 1 | 908 | table_id: 71 flags: STMT_END_F |
| binlog.000009 | 908 | Xid | 1 | 939 | COMMIT /* xid=32 */ |

-- slave's binlog:
| binlog.000005 | 1929751 | Gtid | 1 | 1929799 | SET @@SESSION.GTID_NEXT= '12446bf7-3219-11e5-9434-080027079e3d:7206' |
| binlog.000005 | 1929799 | Query | 1 | 1929867 | BEGIN |
| binlog.000005 | 1929867 | Query | 1 | 1929936 | COMMIT |

And the 7206 seqno is missing on cluster peers.