可以直接忽略

算了，不纠结了。dm改用高版本v7.5的了

本机能看到dumpling进程，大概率脚本在本机上。用grep -ir 找一下关键字呢

那就是没问题

建议从SQL入手排查

1、看属组是tidb，说明大概率是tidb用户执行的； 2、dumpling只能在客户端生成备份文件，说明大概率是本机； 3、看备份的时间是每天一次，可以看下cron.daily目录下有没有备份脚本。

看状态可以用： tiup cluster display cluster_name -R tiki

1、检查tidb日志里是否有Welcome关键字； 2、检查一下异常tidb服务器的网络是否异常

看着是tikv有热点，看看有没有异常的sql

手动装一下，在~/.tiup/components/ctl/vx.x.x看看有没有tar包，解压一下试试

1、部署架构可以先采用混布，即每台机器1个tidb，1个tikv和1个tiflash，测试期间发现组件有瓶颈可以动态扩容。 2、指定万兆的ip即可 3、TiBigdata非官方项目，谨慎使用。

xtrabackup在你这边恢复出来，然后用dumpling + lightning，异构数据库物理备份不通用的

TiDB NB！

可以看看PD->statistics-balance->store leader score 均衡吗？另外可以pd-ctl执行scheduler show，看看有没有迁移leader的sheduler在跑

可以看一下tidb的cpu，慢的时候抓一下火焰图看看。 curl -sl http://127.0.0.1:10080/debug/zip?seconds=60 --output tidb_debug.zip

tikv的服务器有没有部署其他的组件，可以top 按照内存排序看一下

/搜日志welcome关键字，然后再？搜expensive，一般就能查到问题SQL

内存占用计算方式如下： 占用内存=block-cache.capacity (默认值：系统总内存 * 45%)+ ( write-buffer-size * max-write-buffer-number * 4 ) + raft-engine.memory-limit(默认值：系统总内存 * 15%)，所以需要先确认一下tikv配置及tikv实例数量。

1、对于tikv，pd来说，stop建议先手动驱逐leader；tidb，tiflash没有leader的概念。 2、tiup cluster reload会自动驱逐leader，并且更新配置重启。 3、启动是调用systemctl start service-port 命令，所以只要端口对应没问题是不会影响其他组件的。