pd-ctl: add readiness confirmation before PD leader transfer
- Dominant language
- Go
- Stars
- 1.2k
- Forks
- 783
- Avg merge
- 5d 21h
- Merged PRs (30d)
- 36
Description
## Enhancement Task
`pd-ctl member leader transfer ` submits a leader transfer request without checking whether the target PD member has finished loading Region metadata. Promoting an unready member may leave the new leader unable to serve requests for an extended period.
Add a client-side readiness preflight to this command:
- Add a `--force` / `-f` flag.
- Without `--force`:
1. Query the PD member list and resolve the target member's advertised client URLs.
2. Send a direct request to the target member's local leader-promotion readiness endpoint. The request must not be forwarded to the current leader.
3. Submit the leader transfer immediately when the target reports ready.
4. When readiness fails or cannot be verified, print a warning that transferring leadership may cause an extended service interruption and ask whether to continue.
5. Continue only when the operator enters an exact uppercase `Y`; abort for any other input or EOF.
- With `--force`, submit the leader transfer directly without member discovery, readiness checks, or interactive confirmation.
Add tests covering:
- A ready target is transferred without prompting.
- An unready target is not transferred when confirmation is declined.
- An unready target is transferred after an explicit `Y`.
- `--force` and `-f` bypass the readiness preflight.
- The readiness request is sent directly to the selected target member.
This is a CLI-side alternative to #10993 and #10994. Those changes enforce readiness on the server side for multiple leader transfer paths. This proposal keeps an explicit operator override for recovery and other exceptional situations.
Contributor guide
Research direction
Start at the `pd-ctl member leader transfer ` command and trace its member-list and leader-transfer request paths. Add focused CLI tests for readiness, exact-Y confirmation, `--force`/`-f`, and direct targeting; done means each listed behavior is covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100