在 mysql5.6 中创建/删除内存表后，复制因 GTID_NEXT 错误而停止

Question

我们最近在我们的 mysql-cluster 上从 mysql5.5.x/mysql5.1.x 升级到 mysql5.6.25。下面是我们架构的简要快照。

自从我们升级并启用 gtid-mode 以来，我们一直在间歇性地收到类似于以下内容的从属错误：

Last_SQL_Error: 错误 '当@@SESSION.GTID_NEXT 设置为 GTID 时，您必须在 COMMIT 或 ROLLBACK 后将其显式设置为不同的值。请查看 GTID_NEXT 变量手册页以获取详细说明。当前@@SESSION.GTID_NEXT 是“d7e8990d-3a9e-11e5-8bc7-22000aa63d47:1466”。在查询。默认数据库：'adplatform'。查询：'像 X 一样创建表 X_new'

我们的观察如下..

• 这些从站错误只需重新启动从站即可解决。
• 此类错误始终与具有内存存储引擎的表的创建/删除有关。
• Complete-Slave(B) 上的错误在每小时的固定分钟（第 39 分钟）不断出现，并且自我们升级以来一直重复，将近一周。
• 每当其主机重新启动时，都会观察到 Complete-Slave 和 Partial slave 上的错误。
• Cluster-1 和 Cluster-2 有 centos 机器，Cluster-3 有 ubuntu-machines。centos 机器上的 slave 也会在其 master(C/D) 重新启动时失败并显示相同的错误，但 ubuntu 机器上的 slave 不会失败！！

我们暂时能够通过在我们的监控系统上设置一个动作脚本来解决这个问题，该脚本在任何机器上触发从属错误警报。

查看mysql的replication-options doc中的gtid_next部分告诉以下内容

在 MySQL 5.6.20 之前，当 GTID 已启用但 gtid_next 不是 AUTOMATIC 时，DROP TABLE 在非临时表与临时表的组合或使用事务存储引擎的临时表与使用非事务存储引擎的临时表的组合上使用时无法正常工作. 在 MySQL 5.6.20 及更高版本中，DROP TABLE 或 DROP TEMPORARY TABLE 在与这些表组合中的任何一个一起使用时失败并显示显式错误。（错误＃17620053）

这似乎与我的问题有关，但仍然不能解释我的情况。任何解决问题的提示/方向将不胜感激...

编辑： 我设法在 mysql(#77729) 中找到了一个最近报告的类似错误，其描述如下：

https://bugs.mysql.com/bug.php?id=77729

当您在复制主机上使用 Engine MEMORY 的表时，mysqld 在第一次访问该表的查询时在二进制日志中注入“DELETE”语句。这确保了复制从站的数据的一致性。

如果复制是基于 GTID ROW 的，则插入的“DELETE”会中断复制。记录的事件采用 STATEMENT 格式，不会在二进制日志中生成正确的 SET GTID_NEXT 语句。

不幸的是，这个错误的状态被标记为Can't Repeat...

Answer 1

我遇到了类似的问题，产生了相同的错误。在主实例上，我删除了一个数据库。

在奴隶身上留下了一个文件<tablename>.exp（我忘记了它的用途）。

从属复制死亡

last_Error：错误“删除数据库失败；某些表可能已被删除，但数据库目录仍然存在。GTID 尚未添加到 GTID_EXECUTED，并且该语句未写入二进制日志。修复此问题如下：（1）从数据库目录./db_to_drop/中删除所有文件；(2) SET GTID_NEXT='c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066506'; (3) 删除数据库db_to_drop。' 查询时。默认数据库：“db_to_drop”。查询：“删除数据库 db_to_drop”

我删除了该文件，运行SET并重新启动了复制：

设置 GTID_NEXT='c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066506'; 启动奴隶；错误 1837 (HY000)：当 @@SESSION.GTID_NEXT 设置为 GTID 时，必须在 COMMIT 或 ROLLBACK 后显式将其设置为不同的值。请查看 GTID_NEXT 变量手册页以获取详细说明。当前 @@SESSION.GTID_NEXT 为“c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066506”。

这是遵循建议的结果。由于它只是一个开发集群，所以我并不担心它会完全丢失，所以我尝试将其设置为下一个 GTID。

SET GTID_NEXT='c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066507';

（即+1）。重新启动复制，一切恢复正常。