你验证的是spark 3.2.1 tipsark 3.0.0 tidb 6.1.0这个组合么？如果你验证没问题，符合了我的理解，我也初步怀疑是on k8s的事，目前主要的问题是没有排查思路，而同一个环境，spark降到3.0.3就没问题，确实有点不知道怎么搞了

按照我现在的理解，回复一下： spark写入过程：锁表–》预写pk–》预写sk–》提交pk–》释放表锁–》提交sk 根据你前后提交的日志来看，错误发生在预写sk阶段，并且存在重试，按照道理说是有个sql锁了要写的数据，然后乐观锁重试次数超过限制之后失败，至于这个sql是一个查询sql还是因为region分裂造成的锁，目前判断不了，我们找专家看看再给你答复，另外，你看有什么怀疑的慢sql或者其他日志可以放的，也可以继续提交

[image]

已经报名了，现在可以抽奖了 [image]

1、无本地运维力量，或者力量较为薄弱 2、有资源弹性伸缩的需要，有批次的业务上线 3、已上阿里云的用户 跟@xfworld大佬的观点一致。

2021年中国分布式数据库市场报告

tispark和spark的版本分别是多少？另外，失败时间段，tikv和tidb上有没有error级别日志？

对新版本做了少许验证，欢迎参考：https://tidb.net/blog/a84d0ac7

话说我昨天还真没搜到，跟你搜的是一个地方，我搜商堪忧

实际上来讲TiDB兼容Mysql生态的开发框架，所以希望专栏中有越来越得多的应用开发类实践文章。

企业内部管理ERP或者CRM外键应该用的多

你们的TiDB集群，主要承担TP负载还是AP负载？

DBA可以不用熬夜了，部署与运维足够简单，存算分离可以有效的隔离负载，统一的SQL入口

摘取的官方文档，希望对各位大佬有所帮助

https://github.com/pingcap/tispark/wiki/PySpark 参考一下官方的说明，其中： TiSpark 版本 Spark 版本 是否需要 pytispark < 2.0 < 2.3 2.4.x 2.3.x 2.4.x pyspark spark-sumbit 2.5.x > 3.0 简单来说， tispark < 2.0和spark < 2.3，必须使用pytispark tipsark 2.4.x 和 spark 2.3.x 2.4.x 在spark-sumbit情况下使用pytispark，其他情况直接…

https://github.com/pingcap/tispark/wiki/PySpark 参考一下官方的说明，其中： TiSpark 版本 Spark 版本 是否需要 pytispark < 2.0 < 2.3 2.4.x 2.3.x 2.4.x pyspark spark-sumbit 2.5.x > 3.0 简单来说， tispark < 2.0和spark < 2.3，必须使用pytispark tipsark 2.4.x 和 spark 2.3.x 2.4.x 在spark-sumbit情况下使用pytispark，其他情况直接…

https://github.com/pingcap/tispark/wiki/PySpark 参考一下官方的说明，其中： TiSpark 版本 Spark 版本 是否需要 pytispark < 2.0 < 2.3 2.4.x 2.3.x 2.4.x pyspark spark-sumbit 2.5.x > 3.0 简单来说， tispark < 2.0和spark < 2.3，必须使用pytispark tipsark 2.4.x 和 spark 2.3.x 2.4.x 在spark-sumbit情况下使用pytispark，其他情况直接…

新旧机器是否在一个k8s集群？如果在一个k8s，大方向上有两个方案： 1.先扩后缩 2.搭建CDC通道 我比较倾向于CDC通道，在新的服务器上，搭建一个新的集群，在新老集群之间搭建TiCDC同步数据，切换时，首先下线服务，等CDC同步完成，切换数据源，上线新数据库 没实操过，理论推断，各位大佬请补充

征集taik，大佬们贡献点talk