imbajin commented on code in PR #532: URL: https://github.com/apache/hugegraph-doc/pull/532#discussion_r4302866084
########## content/en/docs/quickstart/hugegraph/hugegraph-helm-operations.md: ########## @@ -140,8 +153,13 @@ Partition patrol repairs shard membership; leader balance is a separate manual t Before either task, identify the PD leader through authenticated `/v1/members` (`data.pdLeader.restUrl`) and confirm its `/v1/ready` reports `isLeader: true`. The GET tasks `/v1/task/patrolPartitions` and `/v1/task/balanceLeaders` change cluster state; target that confirmed leader with PD REST credentials. Wait for membership recovery and split/move tasks to finish before balancing leaders; Stores must have fresh heartbeats and groups full, healthy membership. -A busy task returns body `status: 1001`. A follower may return empty success, and leader transfers are asynchronous: +A busy task returns body `status: 1001`. Older images may return empty success from a follower, and leader transfers are asynchronous: HTTP 200 or a transfer plan does not prove completion. Recheck `/v1/partitions`, `/v1/stores` and application errors before further maintenance. + +With the [task response fix](https://github.com/apache/hugegraph/pull/3359), followers return body `status: 100`, naming the known leader's Raft address. +Partition patrol also reports `reallocatedShardGroups` and `offlineShardRequests`; empty results mean no changes were scheduled. +Offline-shard requests do not prove successful repairs. A skipped partition balance returns `{"status":0,"outcome":"skipped"}`; Review Comment: Updated in 5a1f9c6: Explicitly named `/v1/task/balancePartitions` for the skipped outcome (`status: 0` with `outcome: skipped`), and `/v1/task/balanceLeaders` for `{}` when no transfers are needed, avoiding JSON key order assumptions in both EN and CN docs. ########## content/en/docs/quickstart/hugegraph/hugegraph-helm-operations.md: ########## @@ -31,10 +31,16 @@ 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. +Keep the chart's single-PD readiness-based liveness workaround for older images. Review Comment: Updated in 5a1f9c6: Clarified that single-PD deployments remain readiness-based due to chart template helper defaults, and documented the supported `pd.livenessPath=/v1/health` override (which also sets startup probe path) for fixed images in both EN and CN docs. ########## content/en/docs/quickstart/hugegraph/hugegraph-helm-operations.md: ########## @@ -127,6 +133,13 @@ Use `store.updateStrategy.type=OnDelete` for a controlled maintenance rollout, a Delete one Store Pod at a time. Before replacing the next, verify the previous Pod is Ready, has a fresh Store heartbeat and each shard group has its full membership and exactly one leader, read from the PD leader. PD's `Up` status alone does not prove completed shard recovery. PDBs limit voluntary eviction, not StatefulSet controller disruption. Stop on missing members or leaders. + +Images containing the [Store registration fix](https://github.com/apache/hugegraph/pull/3362) register `Up` after local engine restore +and report `Offline` on graceful shutdown. Upgrade PD before Store to enable the restore gate. +Temporary Offline reports preserve the existing keepalive window without renewing it; expiry still applies if the Store does not return. +After successful local restore, stream reconnects register `Up` directly without repeating recovery. +PD's authenticated Store responses expose `heartbeatAgeMillis` (`-1` if unknown); compare it with the Store heartbeat period (fixed at 30 seconds). +An age of several times 30000 ms marks a stale `Up` record. Fresh heartbeats and local restore do not prove Raft catch-up, so retain the manual barrier. Review Comment: Updated in 5a1f9c6: Labeled `heartbeatAgeMillis` as PD wall-clock-derived (`max(0, currentTimeMillis - lastHeartbeat)`) and advised verifying actual heartbeat timestamps or registration records after clock adjustments in both EN and CN docs. -- 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]
