imbajin commented on code in PR #3403: URL: https://github.com/apache/hugegraph/pull/3403#discussion_r4369944732
########## docs/server-runtime.md: ########## @@ -973,6 +973,34 @@ configured storage limit, PD marks the space's graphs CPU and memory limits configure Kubernetes namespace quotas when `server.use_k8s=true`; they do not impose process limits in other deployments. +Deleting a graph space also removes its exact PD storage-limit/usage record after +all its graphs have been removed. An empty space that still exists retains its limit +and reports zero usage. Cleanup is idempotent; if PD cleanup fails, the Server keeps +the space configuration and reports the failure so deletion can be retried. Graphs +already deleted are not restored. PD rejects cleanup while the space still has graph +metadata and rechecks current graphs before recreating a missing usage record, so an +older quota collection cannot recreate a deleted space's statistics. This does not +purge records left by deletions before the upgrade. Upgrade PD before Server: older +PD versions do not implement the new `DeleteGraphSpace` RPC and deletion will fail +at the cleanup step until PD is upgraded. This cleanup does not serialize graph +creation with space deletion across Server replicas; avoid creating graphs in a space +while deleting it. + +If cleanup is refused, the Server response includes the PD reason, remaining +record count and up to ten PD graph names (each limited to 128 characters). +Inspect PD's authenticated `GET /v1/graphs` endpoint for the full identifiers and Review Comment: Minor, non-blocking: the recommended `GET /v1/graphs` listing is not complete for this recovery step. At this head, `GraphAPI.getGraphs()` filters to names ending in `/g`, while `ConfigService.deleteGraphSpace()` rejects every record under the space prefix, including schema `/m` records. If such names are truncated or exceed the ten-name diagnostic limit, the recommended listing will not supply the remaining full identifiers. Please point this paragraph (and the matching exception hint) to the existing `GET /v1/partitionsAndStats` diagnostic endpoint: `PartitionAPI.getPartitionsAndStats()` retains every graph-name key, including records with no partitions. No new API or automatic deletion is needed. This is a static source-trace finding at `ed61fdcc422acbfc07c52b06736dc31e7017af4a`; I have not exercised historical-orphan recovery against a running cluster. -- 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]
