因为此类问题尽管不常见，然而每次遇到排查都会破费大量的工夫，整顿整个 case，供参考
背景：
客户报障他们只有一连贯到 TDSQL 抽取数据，差不多 10 分钟左右就会呈现超时中断，重复几次都不胜利。连到 MySQL 却没有任何问题。
排查过程：
一、看到这个问题，的确比拟懵，除了能看到客户用了咱们的 DCDB 产品之外，不分明产生了什么事。
首先和客户确认，他们用的什么工具做的数据抽取，反馈是 DataX。先理解一下 DataX 是什么东东。
DataX 是一个异构数据源离线同步工具，致力于实现包含关系型数据库(MySQL、Oracle 等)、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳固高效的数据同步性能。
为了解决异构数据源同步问题，DataX 将简单的网状的同步链路变成了星型数据链路，DataX 作为两头传输载体负责连贯各种数据源。当须要接入一个新的数据源的时候，只须要将此数据源对接到 DataX，便能跟已有的数据源做到无缝数据同步。
二、信息还是比拟少，持续收集信息
客户声音：
“我可能确定的是，不是框架限定了连接时间，因为同样的代码，连传统 mysql 没有问题（超过两个亿，半个多小时以上），一连 TDSQL 抽取 10 分钟后就报 Timeout。这个问题曾经重大影响到上游零碎，请帮助解决”
客户所能提供的信息也比拟无限，进一步深刻来查。
首先狐疑到了 DataX 和 DCDB 的兼容性，客户反馈之前有导出胜利的案例，故排除。
还是得从 DataX 工具动手，剖析日志发现，DataX 的框架里会主动设置 net_write_timeout=600，这个 600s 和客户反馈的没到 10 分
钟左右就会超时的报障吻合。
查看官档：
netTimeoutForStreamingResultsWhat value should the driver automatically set the server setting ‘net_write_timeout’ to when the streaming result sets feature is in use? (value has unit of seconds, the value ‘0’ means the driver will not try and adjust this value)Default: 600Since version: 5.1.0
明确这里是 JDBC 的属性，导致每一个会话都会把参数 net_write_timeout set 成 600s
批改代码：
jdbcUrl 前面加上参数 netTimeoutForStreamingResults=28800
再次启动 DataX 抽取 DCDB 中的数据，顺利完成！后续也再未呈现相似问题。
剖析：
客户在 MySQL 上跑不会超时应该是可能因为后果集绝对小，jdbc 没启用 streaming result set 的个性，所以不须要设置
这个参数 netTimeoutForStreamingResults
官网参考文档：https://dev.mysql.com/doc/con…
教训证，sqoop 抽取数据时也有同样的问题。