我们基于 Dumpling + Redis + S3 兼容存储，搭建了对外提供 API 的多租户数据导出平台。想和大家探讨：
- 多租户并发导出场景，如何做资源隔离，避免拖垮整个 TiDB 集群？
- 超大表导出 + 流式上传 S3，有哪些稳定性优化技巧？
- Dumpling 任务调度，常见的故障点有哪些？
1、使用单独的tidb节点提供服务、单独的用户，配置资源管控
如果是局域网搭建的话,保证网络稳定就是基础
通过租户级限流、SQL 资源管控实现导出资源隔离，调优 Dumpling 分片与批次参数保障流式上传 S3 稳定，重点规避快照过期、网络颠簸、S3 写入超限三类调度故障。
从 TiDB 的 Raft 实现来看，leader 迁移和 Region 调度都是异步的。集群出现性能抖动时，经常是 PD 在做 rebalance。理解了调度机制，就能理解为什么有时需要手动调 scheduler 参数。
遇到过几次热点问题，排查下来都是自增主键惹的祸。高并发写入全挤在一个 Region 上，改成 AUTO_RANDOM 分配 ID 后就解决了。建议建表时就规划好主键策略。
从auto_increment 改为auto_random 你们怎么搞的，拉出一个新表出来，最后交换表名嘛
Dumpling 无租户隔离，若共用连接或未限制并发（-t ）、单文件大小（-F ），易引发 TiDB OOM、PD 过载（尤其大表/大 Region 数集群）
启用 TiDB 只读节点专供导出，物理隔离业务读写
第一个问题可以试试划分资源组
Dumpling 任务调度，常见的故障点： GC（垃圾回收）未及时延长、 PD 过载（尤其大 region 集群）、 TiDB OOM 或内存超限
平台以 Dumpling 实现数据库数据抽取，利用 Redis 承载任务队列、缓存及状态管理，结合 S3 兼容存储存放导出文件，同时对外开放 API，实现多租户模式下的数据导出能力。
资源隔离：部署独立只读 TiDB 节点、专用账号 + 资源组限流，管控 Dumpling 并发与分片参数，避免导出影响业务。
大表 + S3 导出：按 Region 分片导出，控制单批上传量，保障网络稳定，适配 S3 写入限制。
调度故障 & 规避：提前延长 GC 时长防快照失效；严控并发避免 TiDB OOM；导出期间调低 PD 调度压力；自增主键改为AUTO_RANDOM解决 Region 热点。
防止网络波动