为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
tipd三台+tidb 3台 + tikv 3台的集群（v3.0.9版本）
【概述】 场景 + 问题概述
现在其中一台tikv内存告警，需要关机维护 ，这台tikv在关机前要如何操作？是在中控机上直接关掉tikv的服务，还是说要将这台有故障的tikv从集群中缩容的方式删除，处理好后再扩容回去？
【问题】 当前遇到的问题
现在其中一台tikv内存告警，需要关机维护 ，这台tikv在关机前要如何操作？是在中控机上直接关掉tikv的服务，还是说要将这台有故障的tikv从集群中缩容的方式删除，处理好后再扩容回去？
这本来应该是很简单的事，但我看网上与论坛没有这方面的维护文档，麻烦大家分享下有无相似的处理过程，多谢。
【业务影响】
暂无
【TiDB 版本】
V3.0.9
谢谢。但 一直是offline状态，感觉tikv的维护好麻烦，关个机维护都不容易（单机的话，怎么kill都没事，集群就不同，管理信息没同步到tidb的pd节点的话，很可能管理上就不正常了）。
另外，请教下：ansible-playbook stop.yml -l 10.10.1.66 是表示仅stop 这台主机的服务么？重新开机后在中控机上ansible-playbook start.yml -l 10.10.1.66 能恢复正常状态么？谢谢。
首先建议你升级到4.0以上版本，用tiup接管集群运维会方便很多。
-l 参数就是只对指定的节点操作
好的。多谢。
非常感谢。不过我还是有以下几点想打扰下你：
1）升级到4.0以上时，数据不会有什么兼容问题吧？tiup来停服务应该就方便多了吧？我先测试下。
2）pd-ctl -u “http://10.10.2.63:2379” -d store delete 5 和pd-ctl -d -u “http://10.10.2.63:2379” -d store delete 5 (-u前面多了-d,说是动态删除的意思) 的区别在哪里呢？
3）如果某节点一直不能成为Tombstone状态（我在数据量很小的v3.0.9测试环境都是这样，因为生产仍是v3.0.9），能不能在pd将这个故障节点的相关信息清理掉？
如果实在不同，我就只好先升级看看了，多谢。
好的。非常感谢。
2）从文档来看，-d是进入单命令行模式，并没有看到动态删除的说明，你的参考资料是否能发一下
3）offline状态表示tikv正在转移数据，如果一直卡在这个状态可以检查下日志文件，可能是其他tikv磁盘空间不足导致卡住，如果是用tiup的话可以用–force参数强制缩掉，tidb-ansible不太熟不清楚是否能这样玩。不建议通过pd改元数据，容易玩崩。
1）第一点是网上找到的资料，应该不准确；
2）我的测试环境资料很小（一个库一个表，用for循环才写入几千条记录，边写入边操作，以模拟线上环境），是刚搭建好的，想先模拟缩扩容的方式，下线故障tikv，不料store delete 后，一直是offline状态（近2个小时了），没有变为Tombstone状态（此时我直接ansible-playbook stop.yml -l ‘tikv-ip’，再按官网流程最后ansible-playbook start.yml -l ‘tikv ip’）也是不行的，应该此时pd的管理数据不一致了，所以现在那个故障tikv主机暂时不敢下线维护~~，到时上线后数据异常或不能up就麻烦了~~~
综上所述，我先做下从v3.0.9到4.0以上版本的升级测试(根据你的经验，最多能升到什么版本呢，建议下啦)吧，有问题再向你请教，多谢。
如果AP类需求不大的话，可以考虑升级到4.0比较新的版本
嗯，主要是用来大数据分析
5以上版本可以考虑使用5.1.1
v3.0.9，可以直接升到v5.1.1版本不？
另外，v5.1.1是稳定版本吧，上线多久呢？
先不打扰你了，晚安。非常感谢。
3到5不能直接升级，要从3到4到5这样。5.1.1的发版信息可以看下官网版本release页面。
我现在还睡不了，因为，还在加班。。。
辛苦啦。3个tikv的集群，如果其中一个tikv直接关机（或如机器有故障宕机了），会有什么情况？机器重启开机后,一般要做哪些操作？pd节点还能管理到吗？
2）另外，ansible-playbook stop.yml -l 节点ip，这个命令不仅仅是停止服务吧？如果仅仅是停止服务，我直接在中控机上对有故障的tikv执行这条命令，然后关机维护完成后，执行ansible-playbook start.yml -l tikv节点ip ，tikv能正常使用么？tikv要想变为tombstone状态好麻烦。
1、3tikv关机一个没啥影响，数据都还在服务可用，集群元信息也在，可以参考【SOP 系列 18】TiUP 环境恢复 TiKV 副本。如果是tiup管理的集群，tikv重启后会自动恢复（disconnect变成up），ansible不太清楚，应该也差不多吧。
2、tidb-ansible没有深入研究，你可以看下yml文件和关联的shell脚本，里面做了啥应该容易看出来https://github.com/pingcap/tidb-ansible
处理好了。我看了下脚本，就是stop tikv的服务。但换了内存后，我发现一个问题，就是用region check miss-peer 查看时，有些region缺少副本数，但存储肯定是够的，另外我也没有使用存储的别名（搭建时只是指定了存储的ip），能不能为这些缺少replica的region手工指定store （如store 5是存在的）? 多谢。
补充下：
1）store为5的主机内存换好后，tikv的状态是up的。region check pending-peer检查时一些有pending的region都是在store 5上，状态为"is_learner": true，如下：
“pending_peers”: [
{
“id”: 526256,
“store_id”: 5,
“is_learner”: true
}
2）维护过的store 5 , region_count比维护前要少了几千个。
非常感谢你的解答。