# TiKV Leader Loss

## Question

Why did leaders leave or fail on the affected TiKV, and was the trigger
scheduling, slow-store behavior, raft/gRPC failure, process loss, or network?

## Enter When

Use for leader-count drops, leader transfer storms, store unavailable/down,
raftstore or gRPC busy/stuck signals, or a suspected slow store.

## First Batch

1. Locate leader loss by store and exact interval; align it with TiKV service
   state and raft leadership events.
2. Check external scheduler/upgrade/maintenance events and direct
   raftstore/gRPC/process evidence.
3. Check the strongest infrastructure alternative: IO jitter, CPU/allocstall,
   swap, or network reachability on the same store.

## Decision

Leader movement is an outcome, not a root cause. A slow store is confirmed only
when its direct service/storage path aligns with the leader loss. Generic
resource pressure on another node or another time cannot explain it.

## Strongest Alternative And Stop

Compare with a peer store and a pre-event sample. Stop after one trigger
boundary is supported or the exact required store log/metric is unavailable.
Add `service-availability-impact` when customer service loss is plausible.