bitflicker64 commented on code in PR #532: URL: https://github.com/apache/hugegraph-doc/pull/532#discussion_r4294283034
########## content/en/docs/quickstart/hugegraph/hugegraph-helm-operations.md: ########## @@ -127,6 +133,11 @@ 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/issues/3229) register `Up` after local engine restore +and report `Offline` on graceful shutdown. Upgrade PD before Store to enable the restore gate. +PD's authenticated Store responses expose `heartbeatAgeMillis` (`-1` if unknown); compare it with the configured heartbeat interval Review Comment: Minor: "the configured heartbeat interval" does not exist as a setting. The Store heartbeat period is `HgStoreEngineOptions.storeHBInterval`, a `private final int storeHBInterval = 30` documented as "unit: seconds", with no setter or config key (`HeartbeatService.storeHeartbeat` sets `timerNextDelay = options.getStoreHBInterval() * 1000` while the cluster is OK). An operator searching for that setting will find only PD's `store.keepAlive-timeout` (default 300 s), which is the expiry this check is supposed to beat. Since `heartbeatAgeMillis` is in milliseconds, please give the number, for example: "compare it with the Store heartbeat period (fixed at 30 seconds); an age of several times 30000 ms marks a stale `Up` record". The Chinese page has the same wording at line 131 (`可与配置的心跳间隔比较`). ########## content/en/docs/quickstart/hugegraph/hugegraph-helm-operations.md: ########## @@ -140,8 +151,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/issues/3231), followers return body `status: 100`, naming the known leader's Raft address. Review Comment: Minor: this link and the [Store registration fix] link on line 137 point at issues #3231 and #3229, not at the PRs that add the behaviour. Both issues already list several merged PRs (#3231: #3233, #3218, #3260; #3229: #3234, #3218, #3260), so a reader who follows the link can conclude that a current master image already returns `status: 100` or gates `Up` on restore. Those behaviours come only from the still-open apache/hugegraph#3359 and #3362. Please link #3359 and #3362 directly, as line 39 does for #3358, and update the Chinese page the same way (lines 129 and 147). -- 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]
