1、大概情况
在asktom的论坛里面，看到有人提问：一个tikv节点磁盘坏了，现在是down状态，tikv.log里面不停写入太多关于这个节点访问不了的日志信息，占据大量磁盘，她的处理方式如下：
a、根据ip地址，找到这个节点的store id
b、用store delete，来让这个节点处于offline状态，之后快速变成Tombstone状态，他就可以下掉这个节点了。
c、intenvry.ini文件里面，去掉这个节点的ip配置信息。
d、找厂商修复这个节点磁盘，厂商修复后，发现磁盘文件彻底损坏，换了个新的盘给她。
这样的处理后，他发现这个tikv节点，还是加入不了tidb集群，一直处于offline状态，tikv.log日志不停写入，这个的情况该怎么处理呢？根据各位网友的回复和解决过程，整理如下：
2、解决思路
这个节点上的数据已经丢失了，但是集群的数据还在，因为是三副本，所以只要在集群里面下掉这个tikv节点，然后按照添加新节点的方式，加入这个tikv节点，让tidb集群自动补数据进来就可以了。
3、解决方案
a、强行设置tikv节点为tombstone状态
登录pd的server节点，在业务低峰期执行下 tombstone 命令，curl -X POST 'http://{pd_ip}:{pd_port}/pd/api/v1/store/{store_id}/state?state=Tombstone' ，然后观察下 grafana 里 region health 有没有开始进行补副本操作，执行完后，老的store就从offline变成了Tombstone，虽然ip地址没有变化，但是store id从老的值5变成了新的值39124701，这样就开始了补副本的操作。
b、提高补副本的速度
进去命令行模式，使用命令-i，如：./resources/bin/pd-ctl -u "http://${pd_ip地址}:2379" -i
如果集群负载不大的话，可以在 pd-ctl 中按照下面这种方式调整下：
stores set limit 30 --设置所有 store 添加 learner/peer 的速度上限为 30 。
store limit 39124701 45 --单独设置新加的这个 tikv 节点添加 learner/peer 的速度上限为 45
调整后观察下集群的 QPS/TPS 是否有抖动，如果抖动比较明显再把值调整小点