MySQL:从GTID集中删除坏的GTID

Question

MySQL 5.6.35-日志(社区)

如何在不执行重置母版的情况下从GTID集中移除错误手动注入的GTID？

STOP SLAVE;
SHOW MASTER STATUS;

278bfda1-b93d-11e4-801b-14feb5d284bc:1-129116182,
69cf02cd-1731-11e3-9a19-002590854928:1-649285403:1009231661,
708bb615-d393-11e3-a682-003048c3ab22:1-1009669227,
819c985c-d384-11e3-a621-00259002979a:1-234906555,
9204e764-d379-11e3-a5d9-0013726268ea:1-360176454,
c32252c2-1ce5-11e6-8f4b-c80aa91f9ec4:1

我们需要从这个集合中删除GTID 1009231661：

69cf02cd-1731-11e3-9a19-002590854928:1-649285403:1009231661,

有人知道GTID集存储在哪里/如何存储吗？我在5.7文档中看到GTID存储在表中。但它们存放在5.6中的哪里呢？我想关闭服务器，编辑文件，删除坏的GTID，然后重新启动，以便服务器可以拾取并继续。

Answer 1

对于那些以后发现这一点的人来说..。

这是个灾难性的错误。没有办法解决这个问题。必须在全场范围内执行重置母版/更改母版。为什么它会如此灾难性？因为，在多主循环复制中，所有MySQL服务器都需要执行重置主/更改母版。

在MySQL 5.6中，GTID集存储在主BINLOG文件中，因此必须执行重置主程序。但是，当您执行重置主命令时，命令还会将最后使用GTID的服务器重置为0。现在，奴隶的GTID比主服务器还要大。从服务器将跳过事务，直到GTID超过主服务器的从服务器GTID_EXECUTED_SET值。这就是为什么您必须在所有从服务器上执行重置主机/更改主服务器的原因。

执行重置主/更改主后，我们只需转储/恢复受影响的主服务器(也称为主数据库)上正在更新的数据库，以便它们可以同步。

Answer 2

我认为解决这个问题的正确方法是在执行错误的GTID之前运行该奴隶。START SLAVE支持UNTIL子句。阅读更多关于它的这里。

然后，您可以插入一个空事务来跳过坏的事务。

STOP SLAVE;
SET GTID_NEXT="GTID_you_want_to_skip";
BEGIN; COMMIT;
#now resume just as normal:
SET GTID_NEXT="AUTOMATIC";
START SLAVE;

Answer 3

在mysqldump中启用GTID备份数据库时。您可以看到，在文件开始时，它使用以下命令从主服务器中设置gtid：

SET @@global.gtid_purged='GTID_SET';

我在我的复制环境中尝试了它，它成功了。