# Some Peers Stay Apply-Busy During TiKV Startup and Delay Leader Scheduling

Source note: adapted from the Feishu `Storage oncall handbook` <https://pingcap.feishu.cn/wiki/RNzIwCexFiA1uXkRCvzcsIocnVb> and `Raftstore handbook` <https://pingcap.feishu.cn/wiki/HaZTwLVC0iDxngk2hX3cbR33nqn>.

- Phenomenon:
  - After TiKV restarts, some peers stay in an apply-busy state for around a few minutes.
  - `ServerIsBusy` can appear even when raft-log lag is already zero.
  - PD does not transfer leaders onto the restarted TiKV until the startup path fully settles.
- Trigger / Preconditions:
  - TiKV is restarting or coming back after upgrade or maintenance.
  - The affected release line includes the startup behavior tied to apply-busy transition logic.
- Key metrics:
  - `tikv-details -> raft log -> raft log lag`: returns to zero
  - `tikv-details -> Errors -> server is busy -> applystore_busy`
  - `tikv-details -> server -> hibernate peers`
- Root cause:
  - During startup, TiKV must finish applying pending raft logs before it can transition from apply-busy to a normal state.
  - Some peers can remain blocked in that startup state even after raft-log lag is already zero, which delays leader scheduling from PD.
- Workaround:
  - Increase `raftstore.min-pending-apply-region-count` from the default 10 to 50 or 100 when this startup behavior becomes the main bottleneck.
- Fixed version:
  - `v8.5.2` / `v7.5.7`
- Related oncall:
  - v8.5.X upgrade process had slow TiKV region leader callbacks `TICKET-8183`
  - v8.5.3 how to make TiKV scale up faster `TCOC-4544`
  - v8.1 upgrade process showed uneven TiKV restart time `TCOC-3137`