同一个库下不同表进行同步的时候，如果参数SkipCreateDbTable未配置，会由于MDL锁hang住整个库 about dtle HOT 3 OPEN

源端和目标端为同一MySQL实例时有该问题。

snapshot事务从长期来看是可以去除的。但尚需考虑各种情况。

from dtle.

MySQL 8.0.32 为复现该问题, 可能是8.0允许 snapshot存在是执行此类DDL.

Case 2 但触发如下逻辑导致增量不复制

[DEBUG] client.driver_mgr.dtle: skipping a binlogEntry with the same sid as target.: driver=dtle @module=dtle.applier job=a1 sid=00003307-1111-1111-1111-111111111111 timestamp="2023-06-09T18:30:38.958+0800"

简单移除sid检测机制会导致无限循环.

	if txSid == a.MySQLServerUuid {
		a.logger.Debug("skipping a binlogEntry with the same sid as target.", "sid", txSid)
		skipEntry = true // *HERE*
	} else if a.fwdExtractor != nil {

现状

• 凡是源MySQL的TX, 即时不在复制范围, 也会在目标端形成一个空TX
• 当TX sid和目标端为同一sid时, 跳过TX
• 如果源端和目标端是同一MySQL, 若不进行上述跳过, 则会形成循环复制

方案1

• 当TX sid和目标端为同一sid, 且含有dtle.gtid_executed事务/或DDL dtle tag时, 才跳过TX

问题

• 会形成gtid断点

gtid断点方案: 填补in-memory gtid断点, 上传consul (非实时更新)

• 任务重启时, 从consul gtid继续
• 之前被跳过的gtid, 再次跳过

from dtle.

任务初始建表会造成循环复制. 方案

• 先建表, 等目标端建表完成后, 再获取gtid
• 需要机制: dest task建表完成后通知src task
  • by consul, 或
  • by nats
• 考虑使用consul kv/全量进度来表示建表完成 #365

from dtle.