SQL Statements for Controlling Replica Servers REQUIRE_TABLE_PRIMARY_KEY_CHECK  is available as of MySQL 8.0.20. For multisource replication, setting REQUIRE_TABLE_PRIMARY_KEY_CHECK  to  ON  or  OFF  enables a replica to normalize behavior across the replication channels for different sources, and keep a consistent setting for the sql_require_primary_key  system variable. Using  ON  safeguards against the accidental loss of primary keys when multiple sources update the same set of tables. Using  OFF  allows sources that can manipulate primary keys to work alongside sources that cannot. When  PRIVILEGE_CHECKS_USER  is set, setting REQUIRE_TABLE_PRIMARY_KEY_CHECK  to  ON  or  OFF  means that the user account does not need session administration level privileges to set restricted session variables, which are required to change the value of  sql_require_primary_key  to match the source’s setting for each transaction. For more information, see Section 17.3.3, “Replication Privilege Checks” . SOURCE_AUTO_POSITION Makes the replica attempt to connect to the source using the auto- positioning feature of GTID-based replication, rather than a binary log file based position. This option can be used with  CHANGE REPLICATION SOURCE TO  only if both the replication SQL thread and replication I/O thread are stopped. Both the replica and the source must have GTIDs enabled ( GTID_MODE=ON ,  ON_PERMISSIVE,  or  OFF_PERMISSIVE  on the replica, and  GTID_MODE=ON  on the source).  SOURCE_LOG_FILE , SOURCE_LOG_POS ,  RELAY_LOG_FILE , and  RELAY_LOG_POS  cannot be specified together with  SOURCE_AUTO_POSITION = 1 . If multi- source replication is enabled on the replica, you need to set the SOURCE_AUTO_POSITION = 1  option for each applicable replication channel. With  SOURCE_AUTO_POSITION = 1  set, in the initial connection handshake, the replica sends a GTID set containing the transactions that it has already received, committed, or both. 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. This exchange ensures that the source only sends the transactions with a GTID that the replica has not already recorded or committed. If the replica receives transactions from more than one source, as in the case of a diamond topology, the auto-skip function ensures that the transactions are not applied twice. For details of how the GTID set sent by the replica is computed, see Section 17.1.3.3, “GTID Auto-Positioning” . If any of the transactions that should be sent by the source have been purged from the source’s binary log, or added to the set of GTIDs in the  gtid_purged  system variable by another method, the source sends the error  ER_MASTER_HAS_PURGED_REQUIRED_GTIDS  to the replica, and replication does not start. The GTIDs of the missing purged transactions are identified and listed in the source’s error log in the warning message  ER_FOUND_MISSING_GTIDS . Also, if during the exchange of transactions it is found that the replica has recorded 2766