Update TiKV store status information

faq/deploy-and-maintain-faq.md

@@ -266,6 +266,10 @@ PD can tolerate any synchronization error, but a larger error value means a larg
 
 The client connection can only access the cluster through TiDB. TiDB connects PD and TiKV. PD and TiKV are transparent to the client. When TiDB connects to any PD, the PD tells TiDB who is the current leader. If this PD is not the leader, TiDB reconnects to the leader PD.
 
+#### What is the relationship between each status (Up, Disconnect, Offline, Down, Tombstone) of a TiKV store?
+
+You can use PD Control to check the status information of a TiKV store. For the relationship between each status, refer to [Relationship between each status of a TiKV store](/tidb-scheduling.md#information-collection).
+
 #### What is the difference between the `leader-schedule-limit` and `region-schedule-limit` scheduling parameters in PD?
 
 - The `leader-schedule-limit` scheduling parameter is used to balance the Leader number of different TiKV servers, affecting the load of query processing.

pd-control.md

@@ -840,7 +840,8 @@ Usage:
 
 > **Note:**
 >
-> When you use the `store limit` command, the original `region-add` and `region-remove` are deprecated. Use `add-peer` and `remove-peer` instead.
+> - When you use the `store limit` command, the original `region-add` and `region-remove` are deprecated. Use `add-peer` and `remove-peer` instead.
+> - To check the status information (Up, Disconnect, Offline, Down, or Tombstone) of a TiKV store, use PD Control. For the relationship between each status, refer to [Relationship between each status of a TiKV store](/tidb-scheduling.md#information-collection).
 
 ### `log [fatal | error | warn | info | debug]`
 

tidb-scheduling.md

@@ -77,6 +77,16 @@ Scheduling is based on information collection. In short, the PD scheduling compo
     * Whether the store is overloaded
     * Labels (See [Perception of Topology](/schedule-replicas-by-topology-labels.md))
 
+You can use PD control to check the status information of a TiKV store, which is divided into Up, Disconnect, Offline, Down, and Tombstone. The relationship between each status is as follows:
+
++ **Up**: The current TiKV store is providing service.
++ **Disconnect**: When the heartbeat information of PD and the TiKV store is lost for more than 20 seconds, the store status changes to "Disconnect". When the lost time is longer than the time specified by `max-store-down-time`, the store status changes to "Down".
++ **Down**: When the time that the TiKV store lost connection with the cluster is longer than the time specified by `max-store-down-time` (30 minutes by default), the store changes to "Down". In this status, the store starts replenishing peers of each Region on the surviving store.
++ **Offline**: If you manually take a TiKV store offline through PD Control, the store status changes to "Offline". This is only an intermediate status that the store is taking offline. The store in this status performs the operations of leader transfer and Region balance. When the `leader_count/region_count` (obtained through PD Control) shows that both operations of leader transfer and Region balance have been completed, the store status changes to "Tombstone" from "Offline". In the "Offline" status, you should **not** disable the store service and the physical server where the store is located.
++ **Tombstone**: This status indicates that the TiKV store is completely offline. You can use `remove-tombstone` interface to safely clean up TiKV in this status.
+
+![TiKV store status relationship](/media/tikv-store-status-relationship.png)
+
 - Information reported by Region leaders:
 
     Each Region leader sends heartbeats to PD periodically to report [`RegionState`](https://github.com/pingcap/kvproto/blob/master/proto/pdpb.proto#L312), including: