diff --git a/_typos.toml b/_typos.toml index 80787772..992def34 100644 --- a/_typos.toml +++ b/_typos.toml @@ -1,2 +1,3 @@ [default.extend-words] hel = "hel" +AKS = "AKS" diff --git a/src/main/asciidoc/how-to/operations/kubernetes.adoc b/src/main/asciidoc/how-to/operations/kubernetes.adoc index 563c52da..cc00f38f 100644 --- a/src/main/asciidoc/how-to/operations/kubernetes.adoc +++ b/src/main/asciidoc/how-to/operations/kubernetes.adoc @@ -482,7 +482,7 @@ readinessProbe: ==== Prefer the dedicated liveness endpoint `/api/v1/health` for the liveness probe: it never reports a busy state, so a warming-up node is not restarted. Keep `/api/v1/ready` for the readiness probe. The chart's default value tables below reflect the chart's current defaults; override `livenessProbe.httpGet.path` to `/api/v1/health` as shown above. See <>. -On a High Availability cluster, set `arcadedb.server.readinessRequiresHA=true` (env `ARCADEDB_SERVER_READINESSREQUIRESHA=true`) to withhold traffic from a node until it has joined the Raft group. +On a High Availability cluster, set `arcadedb.server.readinessRequiresHA=true` (env `ARCADEDB_SERVER_READINESSREQUIRESHA=true`) to withhold traffic from a node until it has joined the Raft group and, once joined, until it is a member of the current Raft configuration and has caught up to within `arcadedb.server.readinessHAMaxLag` log entries (default `100`, env `ARCADEDB_SERVER_READINESSHAMAXLAG`) of the commit index. This keeps a restarted follower with a wiped or lagging log out of Service endpoints during a rolling update, so the write quorum is not dropped. ==== [[kubernetes-values-autoscaling]] diff --git a/src/main/asciidoc/how-to/operations/observability.adoc b/src/main/asciidoc/how-to/operations/observability.adoc index da6d6f46..48aadf70 100644 --- a/src/main/asciidoc/how-to/operations/observability.adoc +++ b/src/main/asciidoc/how-to/operations/observability.adoc @@ -268,7 +268,7 @@ On a High Availability cluster you can make readiness reflect Raft membership so arcadedb.server.readinessRequiresHA=true ---- -When this flag is `true` and HA is active, `/api/v1/ready` returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected, then `204`. The default (`false`) preserves current readiness behavior. See <> for the full StatefulSet example. +When this flag is `true` and HA is active, `/api/v1/ready` returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected. Once a leader is known, a second gate checks that the node is a member of the current Raft configuration and, for a follower, that it has caught up to within `arcadedb.server.readinessHAMaxLag` log entries (default `100`) of the commit index; until then it keeps returning `503` (`Node is not yet in the Raft configuration or has not caught up`). Only then does it return `204`. This prevents a (re)joined follower with a wiped or lagging log from being marked ready mid-catch-up, which would otherwise let a rolling restart drop the write quorum. The default (`false` for `readinessRequiresHA`) preserves current readiness behavior. See <> for the full StatefulSet example. ===== Further reading diff --git a/src/main/asciidoc/reference/http-api/http.adoc b/src/main/asciidoc/reference/http-api/http.adoc index 1caa8e8e..1de93c60 100644 --- a/src/main/asciidoc/reference/http-api/http.adoc +++ b/src/main/asciidoc/reference/http-api/http.adoc @@ -257,7 +257,7 @@ Responses: * https://httpstatuses.io/204[`204`] OK -- server is `ONLINE` * https://httpstatuses.io/503[`503`] server not started yet -When `arcadedb.server.readinessRequiresHA=true` and HA is active, readiness additionally requires the node to have joined the Raft group: it returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected. The default (`false`) preserves the behavior above. See <>. +When `arcadedb.server.readinessRequiresHA=true` and HA is active, readiness additionally requires the node to have joined the Raft group: it returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected. Once a leader is known, a second gate requires the node to be a member of the current Raft configuration and, for a follower, to have replayed the committed log to within `arcadedb.server.readinessHAMaxLag` entries of the commit index; until then it returns `503` (`Node is not yet in the Raft configuration or has not caught up`). This keeps a (re)joined follower with a wiped or lagging log out of traffic during a rolling restart, so the write quorum is not dropped. The default (`false` for `readinessRequiresHA`) preserves the behavior above. See <>. Example: diff --git a/src/main/asciidoc/reference/settings.adoc b/src/main/asciidoc/reference/settings.adoc index b3e1b811..c8aac131 100644 --- a/src/main/asciidoc/reference/settings.adoc +++ b/src/main/asciidoc/reference/settings.adoc @@ -209,6 +209,7 @@ The following plugins are available for ArcadeDB Server: |`server.saltIterations`|Number of iterations to generate the salt or user password. Changing this setting does not affect stored passwords|Integer|65536 |`server.eventBusQueueSize`|Size of the queue used as a buffer for unserviced database change events.|Integer|1000 |`server.readinessRequiresHA`|When true and HA is active, `/api/v1/ready` also requires the node to have joined the Raft group (a leader has been elected). Default false preserves current readiness behavior. See <>. _(Available since v26.7.1)_|Boolean|false +|`server.readinessHAMaxLag`|When `server.readinessRequiresHA` is true, the maximum number of Raft log entries a follower may lag behind the commit index (`commitIndex - lastAppliedIndex`) and still report Ready. Keeps `/api/v1/ready` returning 503 until a (re)joined follower has replayed the committed log, so a rolling restart does not drop the write quorum. See <>. _(Available since v26.7.1)_|Long|100 |`server.logFormat`|Console log format: `text` (default, human-readable) or `json` (one JSON object per line with correlation fields). See <>. _(Available since v26.7.1)_|String|text |`server.logIncludeTrace`|In text log mode, append `[traceId=...]` to each line while a trace is active. Default false preserves current text output. _(Available since v26.7.1)_|Boolean|false |`server.grpcQueryMaxResultRows`|Hard ceiling on the number of rows the gRPC unary `ExecuteQuery` materializes. A request limit at or below this cap is honored; a result that would exceed it fails the call with `RESOURCE_EXHAUSTED` (consistent with the `StreamQuery` `MATERIALIZE_ALL` path) rather than silently truncating, and a client cannot bypass it with a larger limit. Bounds heap usage and protects against limitless-query denial-of-service. The default is lower than `server.grpcStreamMaxMaterializedRows` because the unary response is built and returned as a single gRPC message (also bounded by the max message size), whereas `StreamQuery` emits incrementally. Set to `-1` or `0` for unlimited (removes the DoS protection). _(Available since v26.7.1)_|Integer|100000