为了避免无限的复制循环， MySQL不允许您使用log_slave_updatesand replicate-same-server-id。
当使用GTID时，可能会出现您不会意识到的某些意外情况。
在这种情况下，我们有2个使用GTID的MySQL服务器。GTID的服务器部分已在插图中进行了修改，以使其更加清晰。两台服务器也都log_slave_updates启用了：
到目前为止，没有任何异常。因此，让我们在主机（MySQL A）上写数据：
我们可以看到，第一个事务由其GTID标识，其中uuid与MySQL A匹配，序列号为1。让我们再次写一些数据：
现在，让我们在副本（MySQL B）上进行备份：
备份是一致的，并且匹配两台服务器上的数据。
现在，让我们再次写一些数据：
当然，先前进行的备份不会更改。
突然之间，MySQL A崩溃并消失了……我们将MySQL B提升为新的编写器，并使用它再次写入一些数据：
我们可以注意到GTID改为使用UUID的MySQL的乙。（此信息包含在变量中gtid_executed）。
现在该恢复在MySQL A上的备份了：
然后，我们将MySQL A配置为成为MySQL B的副本：
哇 ！所有事务在MySQL A上的备份被忽略后发生！
实际上，这再次是为了保护我们的用户避免诸如循环复制和无限循环之类的问题。
为了能够复制丢失的事务，是server_id在还原之后和开始复制之前将更改为新的唯一值。然后复制将按预期工作：
总之，如果已启用log_slave_updates并且要从副本副本上创建的备份重新创建主数据库，则必须更改server_id。即使您使用GTID，server_id目前仍要考虑。
如果您打算写回MySQL A，那么更改它server_uuid以避免任何脑裂情况总是更安全的。
来源：MySQL GTID：从副本的备份还原主数据库
https://lefred.be/content/mysql-gtid-restore-a-master-from-a-replicas-backup/
