问题标签 [gtid]

我相信我对从属服务器上的 MySQL 复制有一些问题。在“执行的 GTID 集”下没有一个干净的 GTID，而是有多个 GTID。

我已经尝试过从机重置，但这似乎并没有清除它。

有没有人见过这个？解决此问题的最佳方法可能是什么？

提前致谢

我想在启用 GTID 的情况下为我的 Percona 服务器创建一个副本，但是当我显示从属状态时出现此错误：

通常，我会停止我的从站，重置它，重置主站（在从站上），并从主站获取新的 GTID_PURGED 值。但是这一次，master 有一个非常不寻常的值，我不确定如何确定使用哪个值：

从具有新备份副本的从站中，我得到了这个：

还有一件事，我只是在备份之前清除了主服务器上的二进制日志。自动二进制日志清除设置为 7 天。所以我知道这不是因为错误提示的 bin 日志已被清除。

我正在运行 Ubuntu 14:04 和 Percona 服务器版本 5.6.31-77。

我该如何解决这个问题？master 的 GTID_PURGED 的正确值是多少？

我遵循此页面上的步骤

恢复奴隶。但就我而言， gtid_set 为

当我尝试向从站注入空事务并重新启动从站时，“slave_SQL_Running”仍然是“否”。

它变成了

并且当新数据插入到master时，slave仍然无法同步到master。状态变为：

我怎样才能使这项工作？

我不想做一个完整的转储，因为有很多数据，而 fulldump 需要很多时间。

情况：

我们在 Percona MySQL 5.6.32-78.1 上有一个使用 GTID 的主-主-复制。在服务器上，大约有 10 个数据库，我们设置了slave_parallel_workers=5. 一台服务器用于前端处理，一台用于后端。每周两次或三次，后端服务器上的复制因错误而死

2016-10-25 10:00:01 165238 [Warning] Slave SQL: Worker 4 failed executing transaction '0e7b97a8-a689-11e5-8b79-901b0e8b0f53:22506262' at master log mysql-bin.011888, end_log_pos 9306420; Could not execute Update_rows event on table shop.sessions; Deadlock found when trying to get lock; try restarting transaction, Error_code: 1213; handler error HA_ERR_LOCK_DEADLOCK; the event's master log mysql-bin.011888, end_log_pos 9306420, Error_code: 1213 2016-10-25 10:00:01 165238 [ERROR] Slave SQL: ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756 2016-10-25 10:00:01 165238 [Note] Error reading relay log event: slave SQL thread was killed

可能是什么原因？没有跨数据库的 DML 语句，我认为通过使用 MTS，每个数据库只使用一个线程（MTS 的好处是跨多个数据库使用并行复制）？为什么复制会因死锁而中断？

编辑 2016-10-28：

表的架构看起来像

当时这个错误只发生在后端，从来没有发生在前端服务器上。目前我无法粘贴确切的语句，因为二进制日志已被清除。但是这个 GTID 事务中的唯一语句是对表的基于行的 UPDATE。

我正在尝试从 select 语句创建一个表，它给了我一个 GTID 一致性冲突。[HY000][1786] Statement violates GTID consistency: CREATE TABLE ... SELECT.

什么是 GTID 一致性，如何修复 SQL 语句以避免违规？

在 Debian 8 上使用 Percona MySQL 5.6 sql_slave_parallel_workers=5。有时 GTID 复制会中断，我不知道为什么。我认为 GTID 是按连续顺序执行的，但是在查看状态时

我有点困惑。sql_slave_parallel_workers设置为0现在。但是上面声称的错误是 GTID42679909而不是42679868预期的。这是什么原因。解决上述损坏复制的正确步骤是什么？我不明白的是42679869，理论上可以毫无问题地执行带有 GTID 的事务。但是做一个STOP SLAVE; START SLAVE;不处理它们？！

我们可以通过以下步骤跳过基于 GTID 的复制中的错误：

但是，如果复制使用通道信息运行，那么如何跳过特定通道的事务？

我们可以在stop slave和start slave中给出“for channel”关键字。但是如何跳过特定通道的事务，例如 set GTID_NEXT 命令或什么？

我从 MySQL文档中阅读

使用 GTID 时（即使用 --enforce-gtid-consistency 选项启动服务器时），事务内部不支持 CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 语句。可以在启用 GTID 的情况下使用这些语句，但只能在任何事务之外使用，并且只能在 autocommit=1 的情况下使用

并且非常困惑为什么启用 GTID 时事务内部不支持 CREATE/DROP TEMPORARY TABLE，有人可以更详细地解释一下吗？谢谢！

在 MySQL-5.7 中，我们有 GTID 和传统方法来设置 MySQL 复制。

我们还有一个新参数：

gtid_mode = ON_PERMISSIVE

这意味着我们可以启用 GTID，但也可以以传统方式运行复制。

现在我们已经启用了 MySQL 复制，但是我们如何检查 mysql 复制是否在 GTID 或传统上工作？

谢谢

我最近一直在玩 Mysql Workbench，导出功能有一个不需要的烦人功能（当然是我）。默认情况下，set-gtid-purged 功能在 GUI 中设置为 AUTO，似乎每次您想在没有此参数的情况下导出 - 您必须在 Data Exports - Advanced 选项中将其更改为 OFF。更糟糕的是 - 设置不会被记住。

想检查是否有人找到一种方法为我所做的每个数据库/连接永久设置为关闭？

我什至检查了 wb_options.xml 文件并且该功能设置为 OFF 但这似乎并没有因为某种原因停止它。

谢谢。