可以了，上 aliyun 了

没有官方说明。 但据我了解能支持 <= v6，更加新的版本可能要自己评估是否能接受可能的不兼容。 但是最好能用 client-go 就用 client-go，因为他稳定性可靠性有保障

-r 开启表内并发，dumpling 并没有聚合的逻辑，这个并发处理的数据量少，文件就小。 -r 开启后如何拆分数据是自动的，不是外部能控制的 -F 可以理解为每个并发生成的文件的上限

一直可以使用的，https://tidbcloud.com/. 只是托管在 AWS 上，开放了 5个 region。国内可以选最近的新加坡，相当于数据库部署在新加坡，延迟肯定稍高，你可以自己测具体多少延迟

emm，看了大家的回答，感觉可能是我表述的不太对。 我是这么理解的： Backup&Restore：纯从 TiKV 导入导出 SST file lighting 的物理导入模式：支持各种格式的导入。首先需要把 sql/csv/parquet 等格式编码处理成键值对，然后再直接插入 TiKV Dumpling: 仅支持从 TiDB 读取。 我的问题是，为什么没有这样一个工具：当想导出某一个大表时，从 TiKV 直接读取，然后解码成 sql/csv/parquet 等格式

BR 那不一样啊，只能在 TiDB 之间做备份恢复。 这就和即使有 restore ，还有 lighting 的物理导入道理一样。lighting 的物理导入可以支持各种格式。 虽然有 backup 了，但他并不能导出为其他格式，直接用于分析或者导入到其他数据库。

咱们业务上能否切换成 spark jdbc 写入呢，如果可以推荐做一下切换。 错误原因主要是写入前的 scatterRegion （预切region）失败。考虑到这个错误只在 TiDB 8.1 上出现，可能是兼容性方面的问题，这方面目前官方也没有保证和 TiDB 8.1 的兼容性。 时间变长可能是中间有许多错误，在重试。

It should be fixed in this pr Support localdate convert to date in datetype by shiyuhang0 · Pull Request #2780 · pingcap/tispark · GitHub

Fix in this PR https://github.com/pingcap/tispark/pull/2775.

之前写了一个小 blog

写时候的读取是用于冲突等判断 根据之前的 bechmark, 4000w 的数据用 tispark / spark jdbc 应该都是分钟级别的。如果不需要全局事务还是建议 spark jdbc 你现在的并发度是多少，benchmark 里的是 32。如果低了可以增加 executor 数量/核心数来增加并发

应该是设计的时候没有考虑好，我觉得这个参数不应该影响写入。 提了一个 issue，https://github.com/pingcap/tispark/issues/2756。 但这个问题很好规避 fix 不是很急，我有空再搞一下，或者大家有兴趣也可以贡献

这里上下文就是 learner 了 [image]

感觉确实是日志级别不太合适，但不影响正常功能。欢迎在 client-java contribute

spark-sql 还不支持相应 hint，也无法在 spark-sql 中进行语句级别的配置。 目前应该只能： 在配置文件中配置，但这就不是语句级别的 使用 spark-shell/pyspark 等可编程的方式，可以进行语句级别的配置 spark.tispark.isolation_read_engines https://github.com/pingcap/tispark/blob/master/docs/userguide_3.0.md

https://spark.apache.org/docs/latest/sql-data-sources-jdbc.html JDBC 可以参考这里手动进行分区 [image]

我要挑战

还没有支持 unix_timestamp 的分区裁剪。 https://github.com/pingcap/tispark/blob/master/docs/userguide_3.0.md#partition-table-support [image] 可以到 https://github.com/pingcap/tispark/issues 提一个 feature request

分区定义也要改一下，mysql 协议 datetime 类型应该是yyyy-MM-dd HH:mm:ss 这个格式