# Region Movement And TiKV Scaling

## Question

At which scale-out/scale-in or peer-movement stage is progress blocked: PD
operator generation, snapshot transfer, learner apply/ingest, role switch, or
peer removal/cleanup?

## Enter When

Use for slow TiKV scaling, pending peers, add-learner timeout, snapshot backlog,
region movement, store decommission, or ingest/apply bottlenecks.

## First Batch

1. Identify the operation stage and affected stores/regions.
2. If no operator exists, check scheduler enablement, limits, store state,
   pending/abnormal regions, and PD rejection evidence.
3. If an operator exists, check snapshot send/receive, apply/ingest, disk space,
   store limit, and the named blocking step.

## Decision

Separate operator generation from operator consumption. A low movement rate
does not prove PD scheduling is slow when TiKV snapshot/apply is blocked.
Similarly, pending peers are an outcome until the transfer/apply boundary is
observed.

## Strongest Alternative And Stop

Check workload/storage pressure on the target store as the strongest
alternative. Stop after the exact stage is bounded. Never add/remove stores,
change schedule/store limits, or execute recovery actions.