TiDB的大事务会影响GC的时效性吗?

在确定GC的safepoint时,需要保证safepoint点之前数据没有小于safepoint点的lock以防止commit的primary不被回收,进而保证对应的secondary数据的可决议性。

对于大/长事务,其lock由于一直处于keepalive的保活状态而不会因resolve lock而abort掉。所以safepoint可能一直被这样的事务block在一个较旧的值,进而导致活跃系统版本回收过慢引起性能问题。

请问这方面目前是什么状态?(懒得去看代码直接来发问了)

https://book.tidb.io/session1/chapter6/big-txn-in-4.0.html#63-40-的大事务支持 这个帖子有提到大事务原理,也能看出有一个gc_lifetime,但总觉得没有非常明确地指出这方面的问题。

你好,

大事务运行正如你所说不会因为 gc 而清理掉 lock

目前 tidb 不支持手动 gc,所以事务运行这边提供超时 和 事务使用内存限制,当下一个 gc 到来,旧版本就会被清理掉。

了解了,感谢!我也有研究基于Percolator的事务,也有了解TiDB这方面的探索和优化,也在博客做了总结。建议可以考虑一下我提到的优化。因为有些场景可能确实RMW比较频繁,GC如果有时效性问题可能对性能影响很大。

多谢对 tidb 的关注,这边反馈给研发,可以将文章发到 asktug 截图中的版块中,这边会关注的~

:+1:

你好~

博客连接方便补充在上面的回复中吗?

那啥,解决GC时效性那个方案,已经被dongxu大佬发现问题了。博客中相应内容也更新了哈哈,不过还是贴出来避免踩坑吧。

https://blog.csdn.net/maxlovezyy/article/details/99707690

:call_me_hand:

@户口舟亢-PingCAP 我又想到了解决方案,在博客里也有更新 ,再次推送哈!如果贵司又遇到这样的case可以参考一起讨论下。

分常感谢,感谢您的分享.