From cd13556c9ffb04f589b28691491dc47868537329 Mon Sep 17 00:00:00 2001 From: robfrank Date: Tue, 30 Jun 2026 16:54:40 +0200 Subject: [PATCH] docs: document ha.appendElementLimit setting Add the new arcadedb.ha.appendElementLimit configuration parameter (default 64) introduced in ArcadeData/arcadedb#4753 to the SERVER settings reference. It bounds the number of Raft log entries per AppendEntries batch as a secondary cap to the appendBufferSize byte limit. Co-Authored-By: Claude Opus 4.8 (1M context) --- src/main/asciidoc/reference/settings.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/src/main/asciidoc/reference/settings.adoc b/src/main/asciidoc/reference/settings.adoc index 83e0843f..dbf2c0e7 100644 --- a/src/main/asciidoc/reference/settings.adoc +++ b/src/main/asciidoc/reference/settings.adoc @@ -114,6 +114,7 @@ The following plugins are available for ArcadeDB Server: |Name|Description|Type|Default Value |`backup.enabled`|State of backup lock. Disable for increased performance of massive insertions.|Boolean|True |`ha.appendBufferSize`|AppendEntries batch byte limit for replication (e.g. '4MB'). _Since v26.4.1_|String|4MB +|`ha.appendElementLimit`|Maximum number of Raft log entries per AppendEntries batch. Bounds the per-batch in-memory footprint on the follower during catch-up resync, where many batches may queue before the state machine can apply them. Lowering this value reduces peak heap pressure on followers catching up from a far-behind state. The byte limit (`ha.appendBufferSize`) remains the dominant per-batch heap bound; this element count is the secondary cap that governs when entries are small enough that many fit under the byte limit. Must be a positive integer (>= 1). _Since v26.7.1_|Integer|64 |`ha.clientElectionRetryCount`|Number of retries performed by RemoteDatabase after receiving HTTP 503 NeedRetryException during an election. _Since v26.4.1_|Integer|3 |`ha.clientElectionRetryDelayMs`|Delay in ms between RemoteDatabase election retries. _Since v26.4.1_|Long|2000 |`ha.bootstrapFromLocalDatabase`|When true (default), at first cluster formation peers exchange `(fingerprint, lastTxId)` per database; the highest-`lastTxId` peer is elected as bootstrap source via leadership transfer. Matching peers bootstrap locally with zero bytes transferred; mismatched peers reinstall the leader-shipped full snapshot. _Since v26.5.1_|Boolean|true