使用DataStax Bulk Loader v1.8导出Cassandra表报连接池耗尽问题咨询

执行dsbulk unload命令导出Cassandra表数据时使用配置如下：

dsbulk unload -k keyspace -t table
  --connector.csv.delimiter "^"
  --engine.maxConcurrentQueries=4
  --connector.csv.url
  ...

命令运行过程中触发连接池耗尽报错，后续所有连接Cassandra的请求均出现连接超时问题。
相关环境信息：

• Cassandra版本：2.13
• Cassandra集群配置：共3个节点，单节点配置为64核CPU、124GB内存

• -k keyspace：指定目标表所在的Cassandra键空间名称，是dsbulk操作的必选定位参数
• -t table：指定要导出数据的Cassandra表名
• --connector.csv.delimiter "^"：设置导出CSV格式文件的字段分隔符为^，替换默认的逗号分隔符，避免字段内容本身包含逗号时出现CSV格式解析错误
• --engine.maxConcurrentQueries=4：设置查询阶段同时处于inflight状态的最大请求数，注意该参数仅控制查询请求的并发上限，不直接约束连接池的连接数、单连接请求数，是最容易产生配置误解的参数
• --connector.csv.url：指定导出CSV文件的输出路径，支持本地文件路径、符合规范的分布式存储路径

1. 补全dsbulk连接池相关配置，避免默认配置导致连接超发
   多数人配置时仅设置engine.maxConcurrentQueries，忽略dsbulk的并发是多层控制逻辑：查询并发之外，连接池默认参数会根据集群核数自适应调整，3节点64核的配置下，dsbulk默认会给每个节点创建数十个连接，单连接堆积上百个请求，很容易打满服务端连接阈值。
   调整方式：显式追加连接池配置，不要用自适应默认值：

   --driver.pooling.local.connections-per-host=2
   --driver.pooling.remote.connections-per-host=2
   --driver.pooling.local.max-requests-per-connection=256
   --executor.maxThreads=4
   

   配置后总连接数、单连接请求数、线程数和设置的查询并发4完全匹配，不会出现连接超发的问题。
2. 核对Cassandra服务端native transport连接阈值
   登录集群节点查看cassandra.yaml中两个核心配置：native_transport_max_concurrent_connections_per_ip（单IP最大连接数）、native_transport_max_concurrent_connections（集群总native连接数）。默认配置下这两个值通常很小（单IP默认8、总连接默认256），如果业务应用本身和dsbulk从同一个IP发起连接，很容易占满单IP连接配额，导致业务请求拿不到连接报超时。
   调整方式：针对64核大内存节点，将单IP最大连接数调整为64~128，总native连接数调整为2048以上，滚动重启节点生效；运维导出任务尽量从单独的跳板机发起，不要和业务应用部署在同一台机器上跑，避免抢占业务连接配额。
3. 降低全表扫描对集群的压力，避免服务端队列阻塞
   dsbulk unload默认是全表token范围扫描，默认拆分的查询分片数和集群CPU核数挂钩，3节点64核集群默认会拆出上百个分片，即使查询并发设为4，全表扫描触发的SSTable读、JVM GC压力也会导致节点请求队列堆积，连接长时间不响应，最终出现连接超时、连接池耗尽。
   调整方式：显式设置--engine.splits=12（按单节点4个分片控制），追加--read.timeout=60000拉长读超时阈值；导出任务避开业务高峰，执行过程中观察节点CPU、GC停顿指标，如果GC停顿超过1s，就把查询并发降到2，稳定后再逐步上调。如果已经出现请求阻塞，先执行nodetool tpstats查看native-transport线程池的队列堆积情况，队列打满时先停掉dsbulk任务，等积压请求消化完、连接恢复后再重新跑，避免把整个集群打挂。
4. 规避低版本dsbulk的连接泄漏问题
   dsbulk 1.6之前的版本存在已知的连接泄漏bug：导出过程中如果出现CSV写入失败、网络闪断等异常，已经创建的Cassandra连接不会被正常释放，任务运行时间越长残留连接越多，最终耗尽连接池。
   解决方式：升级dsbulk到1.10及以上的稳定版本；如果任务异常中断，先通过netstat -anp | grep 9042检查客户端侧的残留连接，确认连接释放后再重新启动任务。

内容的提问来源于stack exchange，提问作者Dennis