timeout: influxd-ctl copy-shard occurs error about influxdb-cluster

[JackyeeMe]

@chengshiwen

[JackyeeMe]

Hi @chengshiwen
关于这个问题，我说下场景，大概是一个分片组文件夹（假如是50吧），其中包含4个tsm文件，几乎每个文件都达到了2G，然后我不小心删除了一个数据节点下的50文件夹，所以我执行了复制分片操作，每次开始复制到第三个tsm文件的时候，时间大概已耗时30s，meta节点抛出错误了，对此我特别疑惑，查看了源码，故在此杜撰下我的排查与了解的进展，如有问题，希望您及时指正。

大致执行逻辑：

1. 当我执行 influxd-ctl copy-shard 命令时，它会向 http://localhost:8091/copy-shard 发起一个 HTTP 请求，如果本meta节点非领导节点，会进行Http Request转发，最后由主节点执行该命令

2. 主节点执行时，会有两个步骤的 copy-shard 操作，第一步 CopyShard 方法和第二步 copyShard 方法，下面详细谈下第一步，第二步似乎是维护好meta节点上的分片owner信息，我就不详细展开了

3. 承接上一点，第一步 CopyShard 方法，实例化一个 rpcClient 对象

   • 该对象中含有的配置属性，不确定是 influxdb-meta.conf 还是 influxdb.conf 中去取的，是否取的是influxdb.conf 中的 cordinate 项呢
   • 为什么是元节点与目标数据节点dial建立tcp连接呢，我猜是不是为了告诉目标节点分片所在源节点的坐标信息，然后让目标数据节点主动问源数据节点复制分片呢？我增加 dial_timeout 配置项依旧报错超时
   • 那么，为什么这个 i/o timeout 提示的异常是由meta节点抛出呢，意思是meta节点收不到复制结果的响应导致的超时吗？
   • 这是否和 Linux TCP 超时时间配置有关？

最后，我该怎么做才能实现大分片的复制呢

[chengshiwen]

@JackyeeMe 如果只是误删除，scp是可以解决问题，因为没有改变meta存储的元信息；但是要增加或减少备份，scp就不能改变元信息了

[chengshiwen]

1、h.rpcClient.CopyShard 是 meta 主节点和对应 data 节点通信，告知对方需要和对应的源 data 节点进行通信拷贝数据。dial_timeout 对应的错误是 dial timout 相关的错误，而非 i/o timeout
2、i/o timeout 说明 data 节点通信出了超时问题，172.25.38.119 是否是你的一个 data 节点？

[JackyeeMe]

@chengshiwen
我补充下，因为持续抛出这个问题，无法正常copy-shard，所以我执行了停机并使用Linux的scp 文件远程传输分片文件夹至目标数据节点，最后重启目标数据节点，居然也可以同步两边数据，真的amazing，所以我真的很想知道influxd-ctl copy-shard 是不是就是做了scp的事儿

[JackyeeMe]

172.25.38.119:46704->172.25.38.127:8088

是的，是我不小心 删除了 172.25.38.119 节点的一个分片，然后我发起复制，向 172.25.38.127 节点抓取备用分片信息

您说的是data节点超时问题，我就挺疑惑，因为在拷贝我说的50分片前，之前的几个分片都正常拷贝完了， 也没发生这样的超时现象，当我拷贝50时，次次超时，每次大约过了30s就超时

[JackyeeMe]

@chengshiwen
早上好，这次说的和上条又是另外一个超时问题，今天我又细心的发现试用的这一阵子，时不时会发生当我 执行 influx import 命令时出现的 timeout 异常，我跟踪了一下日志，又是出现failed to store statistics" log_id=0o7lAj_l000 service=monitor error=timeout 这种日志，我想它应该与我写入点时出现的超时有关，然后把各个数据节点重启下再导入就又可以导入了，这种奇怪的现象就是有些摸不着头脑

[chengshiwen]

"failed to store statistics" 这种日志正常，单机偶尔也会经常出现，不影响正常功能

[JackyeeMe]

@chengshiwen
嗨，中午好呀，当发生批量写超时时，然后我尝试仅写入一条数据，就在本数据节点对自己执行写入命令发生了这样的事：

[JackyeeMe]

172.25.38.119:46704->172.25.38.127:8088

是的，是我不小心 删除了 172.25.38.119 节点的一个分片，然后我发起复制，向 172.25.38.127 节点抓取备用分片信息

您说的是data节点超时问题，我就挺疑惑，因为在拷贝我说的50分片前，之前的几个分片都正常拷贝完了， 也没发生这样的超时现象，当我拷贝50时，次次超时，每次大约过了30s就超时

然后昨日说的这个问题，您能给我些解决思路吗？

[JackyeeMe]

@chengshiwen 嗨，中午好呀，当发生批量写超时时，然后我尝试仅写入一条数据，就在本数据节点对自己执行写入命令发生了这样的事：

这个问题当我重启这个数据节点时，就能写入了，否则跟服务假死了一样，能查询能连接，就是不能写入，太匪夷所思了。

[chengshiwen]

然后昨日说的这个问题，您能给我些解决思路吗？

我看看能不能复现，能麻烦你提供下整个测试或复现的详细步骤吗

嗨，中午好呀，当发生批量写超时时，然后我尝试仅写入一条数据，就在本数据节点对自己执行写入命令发生了这样的事。
这个问题当我重启这个数据节点时，就能写入了，否则跟服务假死了一样，能查询能连接，就是不能写入，太匪夷所思了。

以及这整个测试或复现的详细步骤

[JackyeeMe]

或复现的详细步骤

@chengshiwen

硬件资源：数据节点 - 4vCPU8G disk：1TB (IPOS 6500)
Q1：在meta节点调用copy-shard命令对data节点超时复制问题
测试环境
主节点：172.25.38.127
备节点：172.25.38.119
分片号：50（内有3个tsm文件，两个2.1G，一个658MB，一个field.idx）
缘由：我不小心删除了备节点的50分片，然后我发起复制，向主节点抓取备用分片信息
现象：之前的正常拷贝完成的几个分片或许是较小均成功了，50这个分片较大，次次超时，并在meta节点上抛出：copy-shard: operation exited with error: read tcp 172.25.38.119:46704->172.25.38.127:8088: i/o timeout 异常信息
共性：几乎每次过了30s即终止执行，抛出TCP Read超时错误

@chengshiwen
Q2：其实步骤不是很复杂，大致步骤如下：
STEP 1 从旧库导出了一日的行协议规范的SQL文件约30G
STEP 2 使用influx import命令导入它，在我导入完成后的几个小时后，我又开始导入新一日的SQL文件，也约30G
STEP 3 导入命令回车后即发生了{"timeout"}错误信息
STEP 4 于是我尝试仅写入一个数据点，仍然这个错误信息
STEP 5 我使用influx进入数据库，use database到开始查询measurement均可以操作
STEP 6 df -h与df -ih 硬盘资源均富余，未发现明显不够用现象，IOPS也正常

不清楚我这么描述，再结合之前的图您是否能进行复现尝试

[JackyeeMe]

@chengshiwen
Q3：这个问题我单独说，Amazing，我有四个数据节点 4 5 6 7，复制因子2，两个分片各冗余在 4 7 和 5 6，当查询数据时 5 6 节点返回的field均正常，4 7 节点时不时返回field 为null的情况，而且每次为null的字段还在不断变化，太不可置信了。
分片分布图：

SQL：

正常的5 6 节点就不说了，贴下4 7 节点返回数据现象：

[chengshiwen]

@JackyeeMe Q1 和 Q2，我测试复现下看看，找找原因；Q3 看看是否有可能是数据在不断更新写入，参考 #36 遇到的问题

[JackyeeMe]

@JackyeeMe Q1 和 Q2，我测试复现下看看，找找原因；Q3 看看是否有可能是数据在不断更新写入，参考 #36 遇到的问题

@chengshiwen
先在此感谢shiwen对之前问题解答，我这边提个Q4，关于两个冷分片2023-06-25 ~ 2023-07-25这一个月数据散布在两个分片下，如图（看我红框的就行）

我的场景是，我在ID:5 TCPAddr:172.25.38.127:8088这个节点做2023-06-29 ~ 2023-06-30 查询29这一日的数据时，我发现它抛出了个错误，如图

抛开这个错误先不谈，恕我才疏学浅，我疑惑的是：同等时间段内的分片，我也是在ID5上执行的SQL查询，为啥它会调用ID:4 TCPAddr:172.25.38.130:8088的查询，我想这两个节点对于这个同样的分片，无非就是主备关系呀，ID5上应该也查询得到，为啥它就要去调用ID4的，望您给我解答解答《比心^.^》

[JackyeeMe]

@JackyeeMe Q1 和 Q2，我测试复现下看看，找找原因；Q3 看看是否有可能是数据在不断更新写入，参考 #36 遇到的问题

@chengshiwen
hi shiwen
Q3 我得和你说个前提，我复制因子是2，但我偶然发现我程序里写入用consistency=one，不知是否就是这个问题的元凶？

emmm，我感觉不是，我又调整了consistency=all，一样是这个问题，这些数据点是根据time写入的，不会再更新了的，什么原因在搞鬼