问题标签 [gtid]

我们有一个 MySQL 8 复制组。我们如何跳过一些导致从站错误的 GTID 事务。

主题在 DBA 中移动

我需要一些帮助来解决这个问题：

我收到此错误：无法在表上执行 Write_rows 事件.....；键“P​​RIMARY”的重复条目“16XXXXX-\xE790\XXXXXXX-16XXXXXX”，错误代码：1062；处理程序错误 HA_ERR_FOUND_DUPP_KEY；事件的主日志 utilBINLog-bin.000029, end_log_pos 794622875

主/从之间发生故障转移。当主人成为奴隶时，这个错误发生在奴隶上。

此设置使用 GTID/BINLOG。我想避免跳过此错误（将跳过计数器设置为 ...），因为我认为这可能会引起数据库中的不一致。

当我在两个数据库中搜索此记录时，没有与错误中显示的记录相对应的记录。

更多信息 - 当我在机器上显示所有二进制日志时，从站上不存在 binlog utilBINLog-bin.000029：

两周前发生了一次硬故障转移（服务器意外重启），自上次故障转移以来，此事务是否可能“卡住”？

看来slave上的executed_GTID_set（77818f20-e21a-11ea-b443-005056af4111: 1-9605354）比当前master的executed_GTID_set（77818f20-e21a-11ea-b443-005056af4111: 1-9585630）提前了

这怎么可能？

有人说我应该做一个停止奴隶；重置从机；启动slave，但根据mysql doc，这不会改变executed_GTID_set，或者我可以注入一个假事务来告诉slave传递有问题的事务，但我不知道如何检查这个错误是否只涉及一个或多个事务.

我注意到 Gtid_IO_Pos 的值是 0-1-557278，而 Master 上的 gtid_current_pos 是 0-1-557279。

在奴隶上：

关于大师：

我检查了二进制日志，事件顺序正确但内容

在奴隶上：

关于大师：

我怀疑这可能会混淆 CHANGE MASTER TO 声明。

我想知道这是否正常，如果正常，这种GTID差异如何不影响复制？

我正在将数据库附加到主服务器，过了一会儿，我在运行时收到以下错误show slave status，我收到以下错误：

尝试对 GTID 1-XXX-XXXXXXXXX 进行 binlog，这将使用现有的 GTID 1-YYY-YYYYYYYYY 创建一个乱序序列号，并启用 gtid 严格模式。

我不仅会欣赏如何修复它的步骤，而且可能会首先解释为什么会发生此错误。

谢谢！

当我运行时show slave status，我收到以下错误：

谷歌搜索对理解错误原因和解决方法没有多大帮助。有小费吗？

由于 GTID 复制只是一个事务列表，我假设它们也可以回滚或重新提交以重播事件

文档显示进行空交易

所以我假设我们也可以回滚事务或再次提交它，如gtid_next文档中给出的

因此，出于测试目的，我查看从gtid_executed表执行了哪些事务（从这里开始的所有语句都在副本上执行）

选择一些我想回滚/重播的事务，如下所示

然后我按照他们的指示清除日志

但即使在这一切之后，我也没有看到副本上的数据库有任何变化，也没有任何表被改变。

我在这里有什么误解？我使用的是 Windows 10、MySQL 8.0.27 和工作台相同的版本

mysql5. 7.备份工具Xtrabackup，在从库执行全量备份时增加--safe slave backup--slave info参数，主从使用gtid。有库全备份生成的备份文件xtrabackup_slave_info中没有gtid信息。另一个来自图书馆。哪些因素会影响 xtrabackup_slave_Info。