Replication with Global Transaction Identifiers You can change the value of  gtid_purged  in order to record on the server that the transactions in a certain GTID set have been applied, although they do not exist in any binary log on the server. When you add GTIDs to  gtid_purged , they are also added to  gtid_executed . An example use case for this action is when you are restoring a backup of one or more databases on a server, but you do not have the relevant binary logs containing the transactions on the server. Before MySQL 8.0, you could only change the value of  gtid_purged  when  gtid_executed  (and therefore  gtid_purged ) was empty. From MySQL 8.0, this restriction does not apply, and you can also choose whether to replace the whole GTID set in  gtid_purged  with a specified GTID set, or to add a specified GTID set to the GTIDs already in gtid_purged . For details of how to do this, see the description for  gtid_purged . The sets of GTIDs in the  gtid_executed  and  gtid_purged  system variables are initialized when the server starts. Every binary log file begins with the event  Previous_gtids_log_event , which contains the set of GTIDs in all previous binary log files (composed from the GTIDs in the preceding file’s Previous_gtids_log_event , and the GTIDs of every  Gtid_log_event  in the preceding file itself). The contents of  Previous_gtids_log_event  in the oldest and most recent binary log files are used to compute the  gtid_executed  and  gtid_purged  sets at server startup: • gtid_executed  is computed as the union of the GTIDs in  Previous_gtids_log_event  in the most recent binary log file, the GTIDs of transactions in that binary log file, and the GTIDs stored in the mysql.gtid_executed  table. This GTID set contains all the GTIDs that have been used (or added explicitly to  gtid_purged ) on the server, whether or not they are currently in a binary log file on the server. It does not include the GTIDs for transactions that are currently being processed on the server ( @@GLOBAL.gtid_owned ). • gtid_purged  is computed by first adding the GTIDs in  Previous_gtids_log_event  in the most recent binary log file and the GTIDs of transactions in that binary log file. This step gives the set of GTIDs that are currently, or were once, recorded in a binary log on the server ( gtids_in_binlog ). Next, the GTIDs in  Previous_gtids_log_event  in the oldest binary log file are subtracted from gtids_in_binlog . This step gives the set of GTIDs that are currently recorded in a binary log on the server ( gtids_in_binlog_not_purged ). Finally,  gtids_in_binlog_not_purged  is subtracted from  gtid_executed . The result is the set of GTIDs that have been used on the server, but are not currently recorded in a binary log file on the server, and this result is used to initialize  gtid_purged . If binary logs from MySQL 5.7.7 or older are involved in these computations, it is possible for incorrect GTID sets to be computed for  gtid_executed  and  gtid_purged , and they remain incorrect even if the server is later restarted. For details, see the description for the  binlog_gtid_simple_recovery system variable, which controls how the binary logs are iterated to compute the GTID sets. If one of the situations described there applies on a server, set  binlog_gtid_simple_recovery=FALSE  in the server’s configuration file before starting it. That setting makes the server iterate all the binary log files (not just the newest and oldest) to find where GTID events start to appear. This process could take a long time if the server has a large number of binary log files without GTID events. Resetting the GTID Execution History If you need to reset the GTID execution history on a server, use the  RESET MASTER  statement. For example, you might need to do this after carrying out test queries to verify a replication setup on new GTID-enabled servers, or when you want to join a new server to a replication group but it contains some unwanted local transactions that are not accepted by Group Replication. Warning Use  RESET MASTER  with caution to avoid losing any wanted GTID execution history and binary log files. Before issuing  RESET MASTER , ensure that you have backups of the server’s binary log files and binary log index file, if any, and obtain and save the GTID set held in the global value of the  gtid_executed 3459