一、概述

在分库分表同步的过程中，不同的 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，

   1. 下图中 ID3 即不需要 skip

   2. 如果已经收到 activeDDLItem

      1. 如果该 DML 在 active 前面，不需要 skip
      2. 如果该 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

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

版权声明：本文为 TiDB 社区用户原创文章，遵循 CC BY-NC-SA 4.0 版权协议，转载请附上原文出处链接和本声明。
https://tidb.net/blog/80c41c9d