问题背景与错误现象
GTID（全局事务标识符）是MySQL中用于简化主从复制管理的一种机制。当用户决定关闭GTID模式，可能因为兼容性或特定操作需求。但在关闭过程中，如果操作不当，很容易引发复制错误3112，其典型错误信息类似于"Error executing row event: 'Cannot execute statements because there are other transactions in progress'"。这个错误会导致从库停止复制，需要手动干预修复。
错误原因分析
错误3112的产生通常与GTID模式的关闭方式有关。在GTID模式下，每个事务都有一个唯一的全局标识。当关闭GTID时，如果主库上还有未提交的事务，或者从库的relay log中包含了基于GTID的事件，而系统试图以非GTID模式处理这些事件时，就会发生冲突。此外，如果关闭GTID后没有正确重置复制状态，也可能导致从库试图应用与当前模式不匹配的事务日志，从而触发错误。
更具体地说，在关闭GTID的过程中，如果没有确保所有事务都已完成，或者没有清除与GTID相关的元数据，那么从库在尝试应用旧的事务日志时，可能会遇到事务边界不清晰的问题，导致系统误认为有多个事务同时进行，违反了某些内部约束。
实战修复步骤
首先，停止复制进程：在从库上执行 `STOP SLAVE;` 命令。然后，检查主从状态：使用 `SHOW SLAVE STATUS\G` 查看错误详情和复制位置。接下来，需要跳过导致错误的事务：如果错误是孤立的，可以尝试设置 `SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;` 来跳过一个事务，但这种方法需谨慎，可能只适用于特定情况。
更彻底的修复方法是重新初始化复制。这包括：在主库上创建一个完整的数据备份，确保在非GTID模式下。然后，在从库上重置复制：执行 `RESET SLAVE ALL;` 清除所有复制设置。接着，恢复备份到从库，并使用 `CHANGE MASTER TO` 命令重新配置主从连接，注意指定正确的日志文件和位置，且不使用GTID参数。最后，启动复制：`START SLAVE;` 并监控状态是否正常。
在整个过程中，确保主从服务器的时间同步，并验证配置文件中GTID相关参数（如gtid_mode、enforce_gtid_consistency）已正确设置为关闭状态。如果问题仍然存在，可能需要检查二进制日志格式和事务隔离级别等其他因素。
预防措施与总结
为了避免类似错误，在关闭GTID模式前，应确保主从复制处于一致状态，所有事务都已提交。建议在维护窗口进行，先停止所有写入操作。关闭GTID后，立即重启MySQL服务以清除内存中的GTID状态。定期监控复制延迟和错误日志，以便及时发现问题。
总之，错误3112通常是由GTID模式切换不当引起的。通过理解其根本原因，并按照系统化的步骤修复，可以有效恢复复制。在实际操作中，备份数据、逐步验证是保证安全的关键。
引用来源：基于MySQL官方文档关于GTID和复制错误的说明，结合社区论坛中的实际案例讨论，例如来自Percona博客和Stack Overflow的相关技术文章，具体参考了MySQL 8.0 Reference Manual中"Replication with Global Transaction Identifiers"章节以及错误代码3112的常见解决方案。这些信息截至2023年10月仍有参考价值。