标签: gtid

我最近打破了复制，当我试图通过一个不正确的交易时。我得到了以下内容。

MariaDB [(none)]> STOP SLAVE;
Query OK, 0 rows affected (0.05 sec)

MariaDB [(none)]> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
ERROR 1966 (HY000): When using parallel replication and GTID with multiple replication domains, @@sql_slave_skip_counter cannot be used. Instead, setting @@gtid_slave_pos explicitly can be used to skip to after a given GTID position.
MariaDB [(none)]> select @@gtid_slave_pos;
+---------------------------------------------+
| @@gtid_slave_pos                            |
+---------------------------------------------+
| 0-1051-1391406,1-1050-1182069,57-1051-98897 |
+---------------------------------------------+
1 row in set (0.00 sec)

MariaDB [(none)]> show variables like '%_pos%';
+----------------------+---------------------------------------------------------+
| Variable_name        | …

我们最近在我们的 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） …