MySQL多线程复制遇到Error_code- 1872的解决方案

文章分享：MySQL主从复制中Error_code: 1872错误的解决方法

在IDC机房遭遇断电后，我们的MySQL数据库遭遇了挑战。今天，我要为大家分享遇到的一个问题——Error_code: 1872，以及相应的解决方案。这并非高深的秘密，但希望对小有兴趣的朋友们能有所启发。

当我们的数据库版本为MySQL 5.7.10时，从服务器在复制时报错，显示错误为：Slave failed to initialize relay log info structure from the repository，Error_code: 1872。这究竟是怎么回事呢？

问题源于多线程复制（MTS）。在MTS的场景下，可能会出现事务回放顺序混乱和执行位置不准确的问题。想象一下，当存在事务间隙（gap事务）时，后面的事务可能会比前面的事务更早执行。例如，事务tx2和tx4可能已提交，但事务tx1和tx3尚未提交。这就是所谓的gap事务。在基于logical_clock的MTS场景下，用户可以通过设置参数slave_preserve_mit_order=1来保证提交的顺序性。

即使在设置了slave_preserve_mit_order=1的情况下，Exec_Master_Log_Pos仍然可能不准确。当发生崩溃时，master info中记录的可能仍然是旧的事务开始位置。这是因为MTS场景下对表slave_realy_info_log的更新并不是事务性的。尽管如此，MySQL在恢复时会比较Exec_Master_Log_Pos和表slave_worker_info中的Master_log_pos，来决定是否需要回放当前事务。

在MySQL 5.7.13之前的版本中，如果遇到宕机情况，需要手动执行特定操作。直接执行CHANGE MASTER TO操作可能会触发上述的1872错误。具体的操作步骤如下：

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;

START SLAVE SQL_THREAD;

由于我们的服务器上的MySQL版本为5.7.10，DBA试图通过CHANGE MASTER TO命令修复复制问题，导致了上述问题。但在MySQL 5.7.13及以后的版本中，这些问题将由MySQL自动修复。也就是说，即使在发生宕机的情况下，复制状态也能准确并自动地恢复。

我们在升级到MySQL 5.7.15的过程中又遇到了新的挑战。关于这次遇到的坑，我们留到下次分享时再详细讲解。希望这次的分享能为大家带来帮助和启发。如果有更多问题或需要进一步的讨论，欢迎随时与我联系和交流。