Replication with Global Transaction Identifiers system variable (for example, by issuing a  SELECT @@GLOBAL.gtid_executed  statement and saving the results). If you are removing unwanted transactions from that GTID set, use  mysqlbinlog  to examine the contents of the transactions to ensure that they have no value, contain no data that must be saved or replicated, and did not result in data changes on the server. When you issue  RESET MASTER , the following reset operations are carried out: Note that  RESET MASTER  is the method to reset the GTID execution history even if the server is a replica where binary logging is disabled.  RESET REPLICA | SLAVE  has no effect on the GTID execution history. •The value of the  gtid_purged  system variable is set to an empty string ( ’’ ). •The global value (but not the session value) of the  gtid_executed  system variable is set to an empty string. •The  mysql.gtid_executed  table is cleared (see mysql.gtid_executed Table). •If the server has binary logging enabled, the existing binary log files are deleted and the binary log index file is cleared. 17.1.3.3 GTID Auto-Positioning GTIDs replace the file-offset pairs previously required to determine points for starting, stopping, or resuming the flow of data between source and replica. When GTIDs are in use, all the information that the replica needs for synchronizing with the source is obtained directly from the replication data stream. To start a replica using GTID-based replication, you need to enable the  SOURCE_AUTO_POSITION  | MASTER_AUTO_POSITION  option in the  CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or  CHANGE MASTER TO  statement (before MySQL 8.0.23). The alternative  SOURCE_LOG_FILE  | MASTER_LOG_FILE  and  SOURCE_LOG_POS  |  MASTER_LOG_POS  options specify the name of the log file and the starting position within the file, but with GTIDs the replica does not need this nonlocal data.. For full instructions to configure and start sources and replicas using GTID-based replication, see Section 17.1.3.4, “Setting Up Replication Using GTIDs” . The  SOURCE_AUTO_POSITION  |  MASTER_AUTO_POSITION  option is disabled by default. If multi-source replication is enabled on the replica, you need to set the option for each applicable replication channel. Disabling the  SOURCE_AUTO_POSITION  |  MASTER_AUTO_POSITION  option again makes the replica revert to file-based replication, in which case you must also specify one or both of the  SOURCE_LOG_FILE |  MASTER_LOG_FILE  or  SOURCE_LOG_POS  |  MASTER_LOG_POS  options. When a replica has GTIDs enabled ( GTID_MODE=ON ,  ON_PERMISSIVE,  or  OFF_PERMISSIVE ) and the  MASTER_AUTO_POSITION  option enabled, auto-positioning is activated for connection to the source. The source must have  GTID_MODE=ON  set in order for the connection to succeed. In the initial handshake, the replica sends a GTID set containing the transactions that it has already received, committed, or both. This GTID set is equal to the union of the set of GTIDs in the  gtid_executed  system variable ( @@GLOBAL.gtid_executed ), and the set of GTIDs recorded in the Performance Schema  replication_connection_status  table as received transactions (the result of the statement  SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status ). The source responds by sending all transactions recorded in its binary log whose GTID is not included in the GTID set sent by the replica. To do this, the source first identifies the appropriate binary log file to begin working with, by checking the  Previous_gtids_log_event  in the header of each of its binary log files, starting with the most recent. When the source finds the first  Previous_gtids_log_event which contains no transactions that the replica is missing, it begins with that binary log file. This method is 3460