Three registered settings landed in the 26.10.1 HA schema-replication batch and none of them has a row in src/main/asciidoc/reference/settings.adoc. grep -rn 'schemaIncrementalApply\|schemaDelta\|schemaBulkDDLScript' src/main/asciidoc/ returns nothing.
Scopes and defaults verified against GlobalConfiguration.java on arcadedb@main:
All three are new in v26.10.1 (the tree is 26.10.1-SNAPSHOT at the time of the merges), so each row wants a _Since v26.10.1_ marker per the table's existing convention. The two ha.* rows sort alphabetically between ha.replicationLagWarning (L165) and ha.serverList (L166).
1. ha.schemaIncrementalApply (SERVER, Boolean, default true)
A follower applying a committed DDL entry instantiates components only for the files that entry created, instead of rebuilding every component in the database. The full rebuild is O(total files) per entry, which made building a large schema quadratic in the number of types: a 1209-type schema took roughly 2h53m to replicate. Entries the incremental path cannot express - anything that retires a file, or that ships a compacted index, a bloom filter, or a new dictionary - fall back to the full rebuild automatically.
Worth stating explicitly: the value is read per entry, so flipping it takes effect on the next applied entry without a restart. Set it to false only to isolate a suspected incremental-apply regression.
2. ha.schemaDelta (SERVER, Boolean, default false)
Ships schema changes to followers as a delta against the schema they already hold, instead of a complete serialization of the schema document on every DDL. On a large schema that is the difference between kilobytes and megabytes per Raft entry, paid on the leader's CPU, on the wire, in every node's Raft log, and in the follower's rewrite of schema.json. The leader falls back to the whole document on its own after a leadership change (the freshness guard is keyed on the Raft term), on the compaction path, on the first schema entry of a database instance's lifetime, and whenever the delta is not meaningfully smaller than the document.
This row needs more than a description, because the setting has a correctness cliff with no runtime guard. Reading a delta requires no configuration; only emitting one is gated. Every node must be on v26.10.1 or later before the setting is turned on. An older node cannot see the delta section - it stops decoding after the sections it knows - so it applies a SCHEMA_ENTRY with an empty schema payload: nothing changes, nothing is logged, and its schema diverges from the leader's silently. There is no peer-capability negotiation, so the leader cannot detect this and protect the operator (tracked as ArcadeData/arcadedb#7219). Turning the setting back off is safe at any time.
The row should carry a short warning and cross-reference the operator-facing subsection proposed in the companion issue for how-to/operations/ha.adoc.
Also worth a clause: while the setting is on, the leader keeps one parsed copy of the schema document per replicated database in heap, released when it goes back off.
3. schemaBulkDDLScript (DATABASE, Boolean, default true)
A SQL script whose statements are all schema-definition DDL runs inside a single schema recording session, so the batch is persisted - and under HA replicated as one Raft entry - once instead of once per statement. The trade is that the database write lock, and the schema recording session with it, are held for the whole script rather than reacquired per statement. Set to false to go back to one session per statement.
Statements that touch records rather than definitions are excluded from batching by design, and a script containing any of them runs per-statement as before: REBUILD INDEX / REBUILD TYPE / REBUILD GRAPH ANALYTICAL VIEW, TRUNCATE TYPE / TRUNCATE BUCKET, REFRESH MATERIALIZED VIEW / REFRESH CONTINUOUS AGGREGATE, COMPACT INDEX, CREATE MATERIALIZED VIEW, CREATE CONTINUOUS AGGREGATE, the graph-analytical-view statements, ALTER TYPE ... WITH repartition = true, and CREATE INDEX on a type that already exists.
Filed from the post-merge pass over ArcadeData/arcadedb#6988, #6989, #6990. Precedent for the batched shape: #445.
Three registered settings landed in the 26.10.1 HA schema-replication batch and none of them has a row in
src/main/asciidoc/reference/settings.adoc.grep -rn 'schemaIncrementalApply\|schemaDelta\|schemaBulkDDLScript' src/main/asciidoc/returns nothing.Scopes and defaults verified against
GlobalConfiguration.javaonarcadedb@main:ha.schemaIncrementalApplytrueha.schemaDeltafalseschemaBulkDDLScripttrueAll three are new in v26.10.1 (the tree is
26.10.1-SNAPSHOTat the time of the merges), so each row wants a_Since v26.10.1_marker per the table's existing convention. The twoha.*rows sort alphabetically betweenha.replicationLagWarning(L165) andha.serverList(L166).1.
ha.schemaIncrementalApply(SERVER, Boolean, defaulttrue)A follower applying a committed DDL entry instantiates components only for the files that entry created, instead of rebuilding every component in the database. The full rebuild is O(total files) per entry, which made building a large schema quadratic in the number of types: a 1209-type schema took roughly 2h53m to replicate. Entries the incremental path cannot express - anything that retires a file, or that ships a compacted index, a bloom filter, or a new dictionary - fall back to the full rebuild automatically.
Worth stating explicitly: the value is read per entry, so flipping it takes effect on the next applied entry without a restart. Set it to
falseonly to isolate a suspected incremental-apply regression.2.
ha.schemaDelta(SERVER, Boolean, defaultfalse)Ships schema changes to followers as a delta against the schema they already hold, instead of a complete serialization of the schema document on every DDL. On a large schema that is the difference between kilobytes and megabytes per Raft entry, paid on the leader's CPU, on the wire, in every node's Raft log, and in the follower's rewrite of
schema.json. The leader falls back to the whole document on its own after a leadership change (the freshness guard is keyed on the Raft term), on the compaction path, on the first schema entry of a database instance's lifetime, and whenever the delta is not meaningfully smaller than the document.This row needs more than a description, because the setting has a correctness cliff with no runtime guard. Reading a delta requires no configuration; only emitting one is gated. Every node must be on v26.10.1 or later before the setting is turned on. An older node cannot see the delta section - it stops decoding after the sections it knows - so it applies a
SCHEMA_ENTRYwith an empty schema payload: nothing changes, nothing is logged, and its schema diverges from the leader's silently. There is no peer-capability negotiation, so the leader cannot detect this and protect the operator (tracked as ArcadeData/arcadedb#7219). Turning the setting back off is safe at any time.The row should carry a short warning and cross-reference the operator-facing subsection proposed in the companion issue for
how-to/operations/ha.adoc.Also worth a clause: while the setting is on, the leader keeps one parsed copy of the schema document per replicated database in heap, released when it goes back off.
3.
schemaBulkDDLScript(DATABASE, Boolean, defaulttrue)A SQL script whose statements are all schema-definition DDL runs inside a single schema recording session, so the batch is persisted - and under HA replicated as one Raft entry - once instead of once per statement. The trade is that the database write lock, and the schema recording session with it, are held for the whole script rather than reacquired per statement. Set to
falseto go back to one session per statement.Statements that touch records rather than definitions are excluded from batching by design, and a script containing any of them runs per-statement as before:
REBUILD INDEX/REBUILD TYPE/REBUILD GRAPH ANALYTICAL VIEW,TRUNCATE TYPE/TRUNCATE BUCKET,REFRESH MATERIALIZED VIEW/REFRESH CONTINUOUS AGGREGATE,COMPACT INDEX,CREATE MATERIALIZED VIEW,CREATE CONTINUOUS AGGREGATE, the graph-analytical-view statements,ALTER TYPE ... WITH repartition = true, andCREATE INDEXon a type that already exists.Filed from the post-merge pass over ArcadeData/arcadedb#6988, #6989, #6990. Precedent for the batched shape: #445.