MySQL报错3990，GTID模式关闭导致异步重连失败，远程帮忙修复方案分享

前段时间,我们线上的一台MySQL从库突然报警，说是复制中断了，错误代码是3990，当时看到这个错误码，第一下子也有点懵，因为平时遇到的都是些更常见的错误，赶紧去查MySQL的官方手册（来源：MySQL 8.0 Reference Manual），上面对这个错误的解释是“在禁用GTID模式时，无法使用MASTER_AUTO_POSITION功能进行连接”。

这句话读起来有点绕,我来拆开解释一下，GTID你可以理解成给数据库里执行的每一条事务（比如增删改查操作）都打上一个全球唯一的标签，有了这个标签，从库就能非常精确地知道该从哪里开始同步主库的数据，不容易出错，而MASTER_AUTO_POSITION = 1这个设置，就是告诉从库：“你启动的时候，自动去用GTID的方式找主库同步，不用我手动指定日志文件的位置了。”

那问题就出在这里了,我们这台从库的配置里，确实设置了MASTER_AUTO_POSITION = 1，意思是它想用GTID这种自动化的方式来同步，我们检查主库的配置时发现，主库的GTID模式（就是gtid_mode这个参数）不知道什么原因被设置成了OFF，也就是关闭状态，这就好比是，从库拿着身份证识别系统（GTID）的凭证想去进门，但主库那边却说：“我们这儿现在不认身份证，只认手写的介绍信（传统的基于二进制日志文件和位置的复制）。”两边对不上号，从库自然就连接失败，抛出了3990错误。

修复的核心思路就很明确了：让主从库的GTID模式配置保持一致，既然从库想用GTID，那我们就得把主库的GTID模式打开，开启GTID可不是简单地在配置文件里把OFF改成ON然后重启数据库就完事了，那样子可能会出大问题，这需要一个严谨的、一步一步来的操作过程，确保数据不会错乱。

下面就是我们当时采取的修复步骤,整个过程我们是在业务低峰期进行的，并且提前做了完整的数据库备份（这是必须的，动生产环境任何配置前都要备份）。

第一步,我们首先登录到主库的MySQL，执行了一个命令：FLUSH TABLES WITH READ LOCK; 这个命令的作用是给主库加一个全局的读锁，让主库暂时变成只读状态，新的数据写入会被阻塞，这样做的目的是为了获取一个一致性的数据快照点，防止在配置变更期间有新的数据写入，导致主从数据不一致。

第二步,在主库加锁之后，我们立刻在另一个会话窗口，使用SHOW MASTER STATUS;命令记录了当前主库的二进制日志文件名（File）和位置（Position），这个信息非常关键，它就是我们后面要用的“手写介绍信”，是传统复制方式下的坐标点，记下这个坐标后，我们才解锁，执行UNLOCK TABLES;，让主库恢复正常的读写。

第三步,开始修改主库的MySQL配置文件（通常是my.cnf或my.ini），我们在[mysqld]这个配置段里，添加或修改了以下几个参数：

gtid_mode=ON
enforce_gtid_consistency=ON

enforce_gtid_consistency这个参数是为了确保所有的事务都能被GTID安全地记录，也是开启GTID的一个前提条件。

第四步,保存好配置文件后，我们重启了主库的MySQL服务，让新的配置生效，重启完成后，再次登录主库，确认gtid_mode和enforce_gtid_consistency的值都已经显示为ON了。

第五步,现在轮到处理从库了，我们登录到出问题的从库，先停止了复制线程：STOP SLAVE;，我们需要修改它的连接配置，既然主库已经开启了GTID，我们就可以继续使用它喜欢的AUTO_POSITION方式了，但为了稳妥起见，我们当时是先切换到了传统的基于位置的复制方式，使用命令：CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE='刚才记录的文件名', MASTER_LOG_POS=刚才记录的位置; 这里填的就是第二步我们记下来的那个“坐标”。

第六步,配置改好后，我们启动从库复制：START SLAVE;，然后立刻检查复制状态：SHOW SLAVE STATUS\G，我们重点关注Slave_IO_Running和Slave_SQL_Running这两个字段是不是都是Yes，以及有没有错误信息，这时候，从库应该会从我们手动指定的那个日志位置开始同步。

第七步,等确认从库已经追上主库的数据，状态完全正常之后，我们做了最后一步切换，我们再次在从库上执行STOP SLAVE;，然后使用命令CHANGE MASTER TO MASTER_AUTO_POSITION = 1;，将复制方式重新切换回GTID的自动定位模式，最后再次START SLAVE;，并检查状态，看到一切正常，Using_Gtid相关的状态显示为从主库自动获取事务，3990错误就彻底解决了。

MySQL错误3990就是一个典型的“配置不一致”问题，修复的关键在于仔细对比主从库的GTID相关配置，然后按照官方推荐的步骤，安全、平滑地开启GTID模式，或者将主从配置统一到一种复制策略上，整个过程就像是在调解两个人的沟通方式，让他们说同一种“语言”，这样合作起来就顺畅了。