mysqldump — A Database Backup Program 491 the set of GTIDs in the global value of the  gtid_executed  system variable is not empty. A  SET @@SESSION.sql_log_bin=0  statement is also included if GTIDs are enabled on the server. In MySQL 5.6 and 5.7, you can replace the value of  gtid_purged  with a specified GTID set, provided that  gtid_executed  and  gtid_purged  are empty. From MySQL 8.0, you can either replace the value of  gtid_purged  with a specified GTID set, or you can add a plus sign (+) to the statement to append a specified GTID set to the GTID set that is already held by  gtid_purged .  mysqldump ’s SET @@GLOBAL.gtid_purged  statement includes a plus sign (+) in a version comment that takes effect when the dump file is replayed on releases from MySQL 8.0, meaning that for these releases, the GTID set from the dump file is added to the existing  gtid_purged  value. For MySQL 5.6 and 5.7, the value of  gtid_purged  is replaced with the GTID set from the dump file, which can only happen when  gtid_executed  is the empty set (so when replication has not been started previously, or when replication was not previously using GTIDs). For the exact details of how the  SET @@GLOBAL.gtid_purged  statement operates, see the  gtid_purged  description for the release where the dump file is to be replayed. It is important to note that the value that is included by  mysqldump  for the  SET @@GLOBAL.gtid_purged  statement includes the GTIDs of all transactions in the  gtid_executed  set on the server, even those that changed suppressed parts of the database, or other databases on the server that were not included in a partial dump. This can mean that after the  gtid_purged  value has been updated on the server where the dump file is replayed, GTIDs are present that do not relate to any data on the target server. If you do not replay any further dump files on the target server, the extraneous GTIDs do not cause any problems with the future operation of the server, but they make it harder to compare or reconcile GTID sets on different servers in the replication topology. If you do replay a further dump file on the target server that contains the same GTIDs (for example, another partial dump from the same origin server), any  SET @@GLOBAL.gtid_purged  statement in the second dump file fails. In this case, either remove the statement manually before replaying the dump file, or output the dump file without the statement. For MySQL 5.6 and 5.7, it is not recommended to load a dump file when GTIDs are enabled on the server ( gtid_mode=ON ), if your dump file includes system tables.  mysqldump  issues DML instructions for the system tables which use the non-transactional MyISAM storage engine, and this combination is not permitted when GTIDs are enabled. If the  SET @@GLOBAL.gtid_purged  statement would not have the desired result on your target server, you can exclude the statement from the output, or (from MySQL 8.0.17) include it but comment it out so that it is not actioned automatically. You can also include the statement but manually edit it in the dump file to achieve the desired result. The possible values for the  --set-gtid-purged  option are as follows: AUTO The default value. If GTIDs are enabled on the server you are backing up and  gtid_executed  is not empty,  SET @@GLOBAL.gtid_purged  is added to the output, containing the GTID set from  gtid_executed . If GTIDs are enabled,  SET @@SESSION.sql_log_bin=0  is added to the output. If GTIDs are not enabled on the server, the statements are not added to the output. OFF SET @@GLOBAL.gtid_purged  is not added to the output, and  SET @@SESSION.sql_log_bin=0  is not added to the output. For a server where GTIDs are not in use, use this option or  AUTO . Only use Note