bitflicker64 commented on code in PR #532: URL: https://github.com/apache/hugegraph-doc/pull/532#discussion_r4307094650
########## content/en/docs/quickstart/hugegraph/hugegraph-helm-operations.md: ########## @@ -31,10 +31,18 @@ Store wait and Helm test reuse existing component images with `curl` already ins PD listens on REST 8620, gRPC 8686 and Raft 8610; Store on REST 8520, gRPC 8500 and Raft 8510; Server HTTP on 8080; Hubble HTTP on 8088. Client Services hide individual Pod addresses. NodePort is a separate allocated port on reachable nodes, not the application listener port. -PD `/v1/ready` requires a Raft leader; `/v1/health` only confirms the listener. Store startup waits for a majority of ready PD peers. +PD `/v1/ready` requires a Raft leader. On older images, `/v1/health` only confirms the listener. +Store startup waits for a majority of ready PD peers. Server waits up to `server.storageWaitTimeoutSeconds` (default 300) before its application startup; adjust it for slow storage bootstrap. No local Helm rendering verifies live cluster reachability, volumes or JVM capacity. +Images containing the [fatal PD health fix](https://github.com/apache/hugegraph/pull/3358) return `503` from `/v1/health` +after a terminal Raft error or shutdown; ordinary elections and quorum loss remain live (`200`). +After a failed snapshot, fix the disk or storage problem before restarting PD: freeing space alone does not reinitialize JRaft. +Because chart templates default probes to `/v1/ready` when `pd.replicas` is 1, single-PD deployments remain readiness-based +regardless of image until chart updates; for fixed images, override `pd.livenessPath=/v1/health` (which also sets the startup probe path) +to enable health-based probe recovery. Review Comment: Important: I missed this in the last round. Documenting the `pd.livenessPath` override, as @imbajin asked, is fine; the problem is the framing "to enable health-based probe recovery", which implies the default single-PD probes do not restart PD after a terminal Raft error. They do. At apache/hugegraph#3358 head e7858813, `/v1/health` and `/v1/ready` read the same probe view, and `RaftEngine.getRaftStatus()` reports ready only for an active state, which `STATE_ERROR` and `STATE_SHUTDOWN` are not. So every 503 from the fixed `/v1/health` is also a 503 from `/v1/ready`, which the chart already uses for startup and liveness when `pd.replicas` is 1. The override only loses coverage. A PD that failed to open its RocksDB (apache/hugegraph#3226, open) stays `STATE_UNINITIALIZED`: `/v1/health` 200, `/v1/ready` 503. The default restarts it after the 300 s startup budget; with the override nothing does. Please say the default `/v1/ready` path already restarts a single PD after a terminal Raft error, describe the override without "enable recovery", and note that `/v1/health` does not detect a PD that never initialises. Same for line 41 of the Chinese page. -- 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]
