一、概述

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

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

一阶段：reSync 之前

开启 reSync

二阶段：reSync 之后

关闭 reSync

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

二、Overview

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

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

原理

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

三、过程

1、一阶段

Skip

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

通过 targetTable 得到对应的 group

通过 sourceTable 得到对应的 activeDDLItem，

下图中 ID3 即不需要 skip

如果已经收到 activeDDLItem

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

如果该 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 DDLs binlog location, initialize to first DDLs location latestLocation binlog.Location // latest DDLs binlog location targetTable *filter.Table allResolved bool }

用到的 ShardingReSync 结构体：

currLocation：用于重定向

latestLocation：用于判断 reSync 是否结束

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

allResolved：与关闭 reSync 有关

3、二阶段

判断是否 skip

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

XIDEvent

RotateEvent

RowsEvent

QueryEvent

4、关闭 reSync

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

四、总结

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

重定向

Skip

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