maxshuang
maxshuang
V4
2021-08-22 加入
获赞
2
回答
6
文章
1
    我理解楼主的意思是担心即使分布式事务拿到了相同的 commitTs ,但是 primary key 先持久化 commitTs 后就认为事务提交了,其他 key 是一个异步的过程,可能会导致 PiTR miss 掉一部分数据。 这是不会的。因为其他 key 没有持久化 commitTs 之前,其他 key 的记录上会有 startTs 的 lock 记录,PiTR 遇到这种 lock 记录会根据事务状态推进或者删除锁,只有等待锁处理之后才会推进 local checkpointTs。 也就是说即使其他节点的 local checkpointTs 已经推进到了某个 commitTs 10,但…
    2 年前
    @TiDBer_ZfRrIo1G 你的表结构可以提供一下排查吗? 具体复现的 DDL/DML 序列看是否能一起提供下 关注: https://github.com/pingcap/tiflow/issues/4736
    2 年前
    @信仰在空中飘扬 https://github.com/pingcap/tiflow/issues/4635 这个 issue 对应的 pr 已经修复了你的问题,是一样的,可以使用新的版本先规避下。 另外: 这个表的 customer_sid 字段是创建表就有的?还是后面 add column 新增?如果是新增的话看是不是能提供下对应的 DDL。 感谢
    2 年前
    你的改的 worker-num 应该是有问题的,mounter 线程数控制的是上游 raw kv 的解码并发,不是到下游 mysql 的并发数,具体链接已经回复在下面,可以先暂时重建下 changefeed 或者 update changefeed 配置。
    2 年前
    这个问题是 TiCDC 当前行分发规则是按 pk/uk 值不同分发到不同线程导致的。死锁的易出现原因是:TiCDC 为了实现 exactly one 语义将 update 拆成了 delete + replace into,导致 MySQL 在 RC 和 RR 隔离级别下都极易出现重合的 gap lock,导致了死锁。 临时措施: (1)https://docs.pingcap.com/zh/tidb/stable/manage-ticdc/#sink-uri-配置-mysqltidb ,将 Mysql Sink 的 worker-count 调整成1;(会影响并发,不过考虑到本来就有比较…
    2 年前