If the result is not empty, the transactions returned are extra transactions that did not originate from the designated source. 

For a replica in a multisource replication topology, repeat the function, for example: 

SELECT GTID_SUBTRACT_UUID(GTID_SUBTRACT_UUID(@@GLOBAL.gtid_executed, server_uuid_of_source_1), server_uuid_of_source_2); 

If the result is not empty, the transactions returned are extra transactions that did not originate from any of the designated sources. 

## Example 17.5 Verifying that a server in a replication topology is read-only 

The stored function GTID_INTERSECTION_WITH_UUID  could be used to verify that a server has not originated any GTIDs and is in a read-only state. The function returns only those GTIDs from the GTID set that originate from the server with the specified identifier. If any of the transactions in the server’s gtid_executed  set have the server’s own identifier, the server itself originated those transactions. You can issue the following statement on the server to check: 

SELECT GTID_INTERSECTION_WITH_UUID(@@GLOBAL.gtid_executed, my_server_uuid); 

## Example 17.6 Validating an additional replica in a multisource replication setup 

The stored function GTID_INTERSECTION_WITH_UUID  could be used to find out if a replica attached to a multisource replication setup has applied all the transactions originating from one particular source. In this scenario, source1  and source2  are both sources and replicas and replicate to each other. source2  also has its own replica. The replica also receives and applies transactions from source source1  if source2  is configured with log_slave_updates=ON , but it does not do so if source2  uses log_slave_updates=OFF . Whatever the case, we currently only want to find out if the replica is up to date with source2 . In this situation, the stored function GTID_INTERSECTION_WITH_UUID  can be used to identify the transactions that source2  originated, discarding the transactions that source2  has replicated from source1 . The built-in function GTID_SUBSET  can then be used to compare the result to the gtid_executed  set on the replica. If the replica is up to date with source2 , the gtid_executed set on the replica contains all the transactions in the intersection set (the transactions that originated from source2 ). 

To carry out this check, store source2 ’s gtid_executed  set, source2 ’s server UUID, and the replica’s gtid_executed  set, into client-side variables as follows: 

$source2_gtid_executed := source2> SELECT @@GLOBAL.gtid_executed; $source2_server_uuid := source2> SELECT @@GLOBAL.server_uuid; $replica_gtid_executed := replica> SELECT @@GLOBAL.gtid_executed; 

Then use GTID_INTERSECTION_WITH_UUID  and GTID_SUBSET  with these variables as input, as follows: 

SELECT GTID_SUBSET(GTID_INTERSECTION_WITH_UUID($source2_gtid_executed, $source2_server_uuid), $replica_gtid_executed); 

The server identifier from source2  ( $source2_server_uuid ) is used with GTID_INTERSECTION_WITH_UUID  to identify and return only those GTIDs from source2 ’s gtid_executed  set that originated on source2 , omitting those that originated on source1 . The resulting GTID set is then compared with the set of all executed GTIDs on the replica, using 

