【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】
【遇到的问题：问题现象及影响】
6月1日下午忽然发现tiflash宕机了，是又宕机了。这已经是第二次了 ，第一次是 下面的帖子
TiFlash 处于Down状态，如何启动和排查原因.
同样的问题又出现了
上次大多数回复是资源问题，是混合部署问题，吸取上次教训，将有问题的节点 下线 ，不在把tiflash与tikv混合部署，但是由于资源有限还是把 tiflash 与 tidb server 放到一台服务器上，内存使用率使用了不到60% ，CPU使用不到10%
观察错误日志发现在故障前出现了不少警告信息
会不会是 把文件引入tiflash后，直接把tikv的表删掉了，从而引发的宕机。
这个时间与系统日志的被杀掉时间是相符的。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
能否回顾下整个操作过程？ 看起来很乱…
然后最好详细描述下，这些操作之后和之前的一些问题…
这个是同一个集群
然后去查系统日志 发现在17点16分有被杀掉的消息
你tiflash不和tikv争抢资源了，换到tidb server上了，那不一样争抢资源吗？。。。
你有几个tidb，多的话把这个机器上的tidb server先缩容掉，让tiflash独占一个机器看下。
另外应该不是你说的这种问题：
会不会是 把文件引入tiflash后，直接把tikv的表删掉了，从而引发的宕机。
这个集群是升级到7.5.1还是全新安装
全新安装的
现在的问题有两个 ，
第一个是如何判断是什么操作引起的这个问题，以后如何避免
第二个是 如果资源竞争，应该资源使用率很高才会出现竞争的问题，可是现在CPU、内存都不高，应该不存在竞争问题 。
tidb也是内存大户 tiflash单独部署
当时出问题时内存才用了不到60% 
我咋跟领导解析，如果它到了80%也好说点 ，现在内存使用这么低，没法说呀
上系统日志，看上面的core解析文件，大概率是内存不足core dump被系统干掉了
我查看了系统检查平台，内存使用率不到60%
select TABLE_SCHEMA,TABLE_NAME,TIDB_TABLE_ID from information_schema.tables where table_id=146376; 看下这个表 你做过什么操作
pd-ctl region 7596696 再看下这个region状态
/var/log/messages 里对应时间点有日志吗？
非不安官方部署 你买的阿里云 本身也是一台虚拟机。tifash表如果坏了 把tiflash 节点下线再上
本地实体机
按开发人员反馈，就是正常的增删改查，最多是 有几个 truncate 操作
