server1> SELECT GTID_IS_DISJOINT($gtid_purged_set, @@GLOBAL.gtid_executed); 

If the result is 1, there is no overlap between the two GTID sets, so no duplicate GTIDs are present. 

•Use GTID_IS_DISJOINT_UNION  to verify that the restore operation resulted in the correct GTID state on server1 . Before restoring the backup, on server1 , obtain the existing gtid_executed  set by executing the following statement: 

server1> SELECT @@GLOBAL.gtid_executed; 

Store the result in a local variable $original_gtid_executed . Also store the gtid_purged  set in a local variable as described above. When the backup from server2  has been restored onto server1 , execute the following statement to verify the GTID state: 

server1> SELECT GTID_IS_DISJOINT_UNION($original_gtid_executed, $gtid_purged_set, @@GLOBAL.gtid_executed); 

If the result is 1, the stored function has verified that the original gtid_executed  set from server1 ( $original_gtid_executed ) and the gtid_purged  set that was added from server2 ( $gtid_purged_set ) have no overlap, and also that the updated gtid_executed  set on server1 now consists of the previous gtid_executed  set from server1  plus the gtid_purged  set from server2 , which is the desired result. Ensure that this check is carried out before any further transactions take place on server1 , otherwise the new transactions in the gtid_executed  set cause it to fail. 

## Example 17.3 Selecting the most up-to-date replica for manual failover 

The stored function GTID_UNION  could be used to identify the most up-to-date replica from a set of replicas, in order to perform a manual failover operation after a source server has stopped unexpectedly. If some of the replicas are experiencing replication lag, this stored function can be used to compute the most up-to-date replica without waiting for all the replicas to apply their existing relay logs, and therefore to minimize the failover time. The function can return the union of the gtid_executed  set on each replica with the set of transactions received by the replica, which is recorded in the Performance Schema table replication_connection_status . You can compare these results to find which replica’s record of transactions is the most up-to-date, even if not all of the transactions have been committed yet. 

On each replica, compute the complete record of transactions by issuing the following statement: 

SELECT GTID_UNION(RECEIVED_TRANSACTION_SET, @@GLOBAL.gtid_executed) FROM performance_schema.replication_connection_status WHERE channel_name = ’name’; 

You can then compare the results from each replica to see which one has the most up-to-date record of transactions, and use this replica as the new source. 

## Example 17.4 Checking for extraneous transactions on a replica 

The stored function GTID_SUBTRACT_UUID  could be used to check whether a replica has received transactions that did not originate from its designated source or sources. If it has, there might be an issue with your replication setup, or with a proxy, router, or load balancer. This function works by removing from a GTID set all the GTIDs from a specified originating server, and returning the remaining GTIDs, if any. 

For a replica that replicates from a single source, issue the following statement, giving the identifier of the originating source, which is normally the server_uuid  value: 

SELECT GTID_SUBTRACT_UUID(@@GLOBAL.gtid_executed, server_uuid_of_source); 

