记录 TiDB v5.2.3 迁移到 v6.1.0 的升级过程
420
2024-03-13
在分库分表同步的过程中,不同的 DDL 之间,还会穿插着各种各样的 DML 语句,这些 DML 语句要如何处理呢?今天就来看看它们的处理过程——reSync。
本节先介绍 reSync 的总流程,然后分为四个部分介绍 reSync:
一阶段:reSync 之前
开启 reSync
二阶段:reSync 之后
关闭 reSync
本节内容皆参考 DM v6.0,对现在而言,有可能已过时,欢迎大家提出意见~
进入 lock 阶段后,在第一次 sync 的时候,会跳过被 active 影响到的 targetTable 对应的 DML
在 Lock resolved 之后,会回到第一次进入 lock 的 binlog Location 点,进行 reSync,把之前 skip 的 DML 重新 sync,这个阶段会跳过上次执行过的 DML。
两种 DML 互相隔离,不会互相影响。
在 handleRowsEvent 的时候,判断该 event 是否需要 skip:
通过 targetTable 得到对应的 group
通过 sourceTable 得到对应的 activeDDLItem,
下图中 ID3 即不需要 skip
如果已经收到 activeDDLItem
如果该 DML 在 active 前面,不需要 skip
如果该 DML 在 active 后面,则 skip
reSync 信号:把 targetTable 和 binlog location 信息传递给主逻辑中,重定向 streamer。
用到的 ShardingReSync 结构体:
currLocation:用于重定向
latestLocation:用于判断 reSync 是否结束
targetTable:用于判断该 DML 是否需要 reSync
allResolved:与关闭 reSync 有关
判断是否 skip
更新 shardingReSync.currLocation 并判断是否要结束 reSync
XIDEvent
RotateEvent
RowsEvent
QueryEvent
如果当前 binlog location 已经越过了 shardingReSync.lastestLocation,则重定向回去。根据是否 allResolved 有两种重定向方式,但貌似没有什么区别?
经过 reSync 之后,悲观协调就结束了。reSync 的过程不是很复杂,主要包括两种操作:
重定向
Skip
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。