bitflicker64 opened a new pull request, #3185:
URL: https://github.com/apache/hugegraph/pull/3185
## Purpose of the PR
- Fixes #3183
- `/v1/health` on PD reports healthy without a raft quorum. This adds a
quorum-aware readiness signal and leaves `/v1/health` as pure liveness.
## Main Changes
- `RaftEngine`: new `hasLeader()`, `isReady()`, `getNodeState()` and
`getAlivePeerCount()`; `isLeader()` and `getLeader()` are now null-safe before
the raft node starts.
- `StoreAPI`: new unauthenticated `GET /v1/ready`. Returns `200` with
`{"ready":true,"state":"STATE_LEADER","leader":"host:8610","isLeader":true}`
while the raft node is active and sees a leader, `503` with `"ready":false`
otherwise. Added to the auth interceptor exclusion list next to `/v1/health`.
- `PDMetrics`: three gauges for alerting on quorum loss: `hg_raft_leader`,
`hg_raft_has_leader`, `hg_raft_alive_peers` (leader only, `NaN` elsewhere).
- Compose files gate Stores on `/v1/ready` instead of `/v1/health`. Docs for
PD, Store and docker updated to explain liveness vs readiness.
Why "sees a leader" is the right local signal: jraft resets a follower's
leader id once heartbeats stop arriving inside the election timeout, and a
leader steps down when it cannot reach a quorum. So a non-null leader id means
this node is inside a quorum from its own point of view, which is what a
readiness probe needs. This matches the behaviour measured in the issue, where
the survivor logged `Raft lost leader` within a second of the fault.
## Verify the Changes
- New `RaftEngineReadinessTest` (added to `PDCoreSuiteTest`) covers: no raft
node, leader, follower with leader, follower without leader, empty leader id,
candidate, transferring, inactive states, and the leadership-loss race in
`getAlivePeerCount()`.
- `RestApiTest` (runs against the live CI PD) now checks that `/v1/health`
and `/v1/ready` need no credentials, that `/v1/ready` reports `ready=true` and
`STATE_LEADER` on the single-node PD, and that the three gauges are exported
with the expected values.
- `test-start-hugegraph-pd.sh` waits for `/v1/ready` to return `200` with
`ready=true` after the health endpoint responds.
- Locally: PD modules built and the core suite run with JDK 11.
## Does this PR potentially affect the following parts?
- Nope
- [ ] Dependencies (add/update license info)
- [ ] Modify configurations
- [x] The public API
- [ ] Other affects (typed here)
Notes for reviewers:
- Kubernetes users should keep liveness probes on `/v1/health` and point
readiness probes at `/v1/ready`. Using `/v1/ready` as a liveness probe would
restart a PD that merely lost its leader.
- The Store's own `/v1/health` is unchanged; this PR only covers PD.
## Documentation Status
- [x] `Doc - Updated`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
