使用DM从MySQL导入数据到TiDB，某个TiKV节点报“TiKV server is busy”

🪐 TiDB 技术问题 备份&数据迁移
,
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】MySQL Server version: 5.7.22-log MySQL Community Server (GPL)

          tidb： v4.0.11
          dm：  v2.0.1
          TiDB集群与DM集群都部署在三台物理机上，使用官方推荐的TiUP工具部署。

【问题描述】

          使用DM集群，将MySQL中的数据使用全量+增量方式迁移到TiDB集群，迁移任务进行到“Load”环节（进度3%左右）就hang住了，一直不变，查看监控显示为直线，但是任务状态是Running，且没有错误。
          后来查看dm-worker的日志，发现日志中有大量“RawCause: Error 9003: TiKV server is busy”日志，如下：

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%871339×248 62.1 KB

通过查看监控图，发现是10.10.119.195这个节点有问题：
%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%871805×598 54.7 KB

于是查看10.10.119.195这个节点的日志，发现也是大量报错“RaftClient send fail”：
%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%871339×443 126 KB 

         之前查看过类似帖子，但是没能解决问题。烦请指导如何排查错误！

         可能用到的信息：

TiKV目前添加了的配置

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%87951×178 13.4 KB

根据 https://docs.pingcap.com/zh/tidb/v3.0/tidb-troubleshooting-map#43-客户端报-server-is-busy-错误 感觉可能是这个问题

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%87920×558 24 KB

2

麻烦先参考上面的链接 https://docs.pingcap.com/zh/tidb/v3.0/tidb-troubleshooting-map#43-客户端报-server-is-busy-错误 ，里面描述的比较详细，可以对照日志和监控逐一排查下原因。

3

能否提供几个监控截图，协助定位下问题所在。一直在按照文档排查，但是文档和监控数据，难以对上，实在无法判断出是哪项导致。刚刚接触，对监控指标不理解，抱歉。

4

麻烦参考下面的方式把 tikv-details 监控面板数据导出下：https://metricstool.pingcap.com/#backup-with-dev-tools

5

tidb1-TiKV-Details_2021-03-09T08_41_57.777Z.json.zip (651.3 KB)
你好，导出的数据如上。由于文件太大，使用zip压缩了。

6

我在 TiDB Dashboard 导出了诊断信息，提示的严重错误是：

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%871373×221 38.3 KB

7

三台云服务器：配置是4C-16G-200GB，刚开通的新机器，资源肯定是够的。
使用DM导出的MySQL数据大小为3.8G左右，也不多。我使用dumpling导出了下，大概610W条记录。

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%871180×275 56.6 KB

8

上面导出的监控页面没有数据，报错 “scheduler is busy” 是由于 scheduler 中由于等待 latch 而阻塞的请求大小超出参数 `scheduler-pending-write-threshold = “100MB” 设置的上限，可以先尝试调整下该参数

9

我刚刚已经调过了，刚重启完TiKV。稍后观察下结果吧。
但是，我感觉增大这个值，好像不是最终的解决办法。这里是加大队列长度，本质上应该从处理速度解决吧，不知是影响处理速度的配置项有哪些。

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%87702×146 14.8 KB

10

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%871817×753 116 KB

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%87942×593 27.5 KB

进度突然从3%调到了83%，但现在又阻塞了。scheduler-pending-write-threshold 这个值确实有影响，我现在设置的是300MB。那这个值应该设置多大合理呢，还请指教。

11

1.参数 scheduler-pending-write-threshold 设置多大需要具体看下负载和机器配置情况，没有标准值推荐，一般情况下都是使用默认值；
2.可以考虑限制下 DM loader 阶段的速度，参考下 https://docs.pingcap.com/zh/tidb-data-migration/stable/task-configuration-file-full：

image
image1520×218 39.6 KB

3.一般在生产环境中使用 DM 迁移数据都是部署在单独的机器上，你这边的部署结构是全部混合部署在三台物理机上，而且机器的配置也不高，容易出现资源抢占的问题，DM 和 tidb 集群部署物理硬件要求情况参考如下：
https://docs.pingcap.com/zh/tidb-data-migration/stable/hardware-and-software-requirements
https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements#服务器建议配置

12

好的，十分感谢。
嗯，现在是测试阶段，正式阶段就应该是分开部署了，谢谢。

13

:handshake:

14

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。