一、大概狀況
在asktom的論壇裏面，看到有人提問：一個tikv節點磁盤壞了，如今是down狀態，tikv.log裏面不停寫入太多關於這個節點訪問不了的日誌信息，佔據大量磁盤，她的處理方式以下：api
a、根據ip地址，找到這個節點的store idcurl
b、用store delete，來讓這個節點處於offline狀態，以後快速變成Tombstone狀態，他就能夠下掉這個節點了。url
c、intenvry.ini文件裏面，去掉這個節點的ip配置信息。spa
d、找廠商修復這個節點磁盤，廠商修復後，發現磁盤文件完全損壞，換了個新的盤給她。命令行
這樣的處理後，他發現這個tikv節點，仍是加入不了tidb集羣，一直處於offline狀態，tikv.log日誌不停寫入，這個的狀況該怎麼處理呢？根據各位網友的回覆和解決過程，整理以下：日誌
二、解決思路
這個節點上的數據已經丟失了，可是集羣的數據還在，由於是三副本，因此只要在集羣裏面下掉這個tikv節點，而後按照添加新節點的方式，加入這個tikv節點，讓tidb集羣自動補數據進來就能夠了。server
三、解決方案
a、強行設置tikv節點爲tombstone狀態ip
登陸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，這樣就開始了補副本的操做。it
b、提升補副本的速度io
進去命令行模式，使用命令-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 是否有抖動，若是抖動比較明顯再把值調整小點