作者： okenJiang 原文来源：https://tidb.net/blog/80c41c9d

一、概述

在分库分表同步的过程中，不同的 DDL 之间，还会穿插着各种各样的 DML 语句，这些 DML 语句要如何处理呢？今天就来看看它们的处理过程——reSync。

本节先介绍 reSync 的总流程，然后分为四个部分介绍 reSync：

• 一阶段：reSync 之前

• 开启 reSync

• 二阶段：reSync 之后

• 关闭 reSync

本节内容皆参考 DM v6.0，对现在而言，有可能已过时，欢迎大家提出意见～

二、Overview

1. 进入 lock 阶段后，在第一次 sync 的时候，会跳过被 active 影响到的 targetTable 对应的 DML

2. 在 Lock resolved 之后，会回到第一次进入 lock 的 binlog Location 点，进行 reSync，把之前 skip 的 DML 重新 sync，这个阶段会跳过上次执行过的 DML。

原理

两种 DML 互相隔离，不会互相影响。

三、过程

1、一阶段

Skip

在 handleRowsEvent 的时候，判断该 event 是否需要 skip：

1. 通过 targetTable 得到对应的 group

2. 通过 sourceTable 得到对应的 activeDDLItem，

3. 下图中 ID3 即不需要 skip

4. 如果已经收到 activeDDLItem

5. 如果该 DML 在 active 前面，不需要 skip

6. 如果该 DML 在 active 后面，则 skip

2、开始 reSync

reSync 信号：把 targetTable 和 binlog location 信息传递给主逻辑中，重定向 streamer。

ShardingReSync

// ShardingReSync represents re-sync info for a sharding DDL group.
type ShardingReSync struct {
    currLocation   binlog.Location // current DDL's binlog location, initialize to first DDL's location
    latestLocation binlog.Location // latest DDL's binlog location
    targetTable    *filter.Table
    allResolved    bool
}

用到的 ShardingReSync 结构体：

• currLocation：用于重定向

• latestLocation：用于判断 reSync 是否结束

• targetTable：用于判断该 DML 是否需要 reSync

• allResolved：与关闭 reSync 有关

3、二阶段

1. 判断是否 skip
   

2. 更新 shardingReSync.currLocation 并判断是否要结束 reSync

• XIDEvent
  

• RotateEvent
  

• RowsEvent
  

• QueryEvent
  

4、关闭 reSync

如果当前 binlog location 已经越过了 shardingReSync.lastestLocation，则重定向回去。根据是否 allResolved 有两种重定向方式，但貌似没有什么区别？

四、总结

经过 reSync 之后，悲观协调就结束了。reSync 的过程不是很复杂，主要包括两种操作：

• 重定向

• Skip

接下来将会开始乐观协调的学习（希望😭