[
https://issues.apache.org/jira/browse/CASSANDRA-19413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818761#comment-17818761
]
Andres de la Peña commented on CASSANDRA-19413:
-----------------------------------------------
[~szymon.miezal] I understand that the original intention of
{{batch_size_fail_threshold}} was to prevent against batches of a specific
size, and not counting the keys would be a bug. If that's the case, we would
usually just fix it.
However, {{batch_size_fail_threshold}} has worked this way for a decade
(CASSANDRA-6487), so many users are probably okay with the current behaviour.
Thus, I would probably go with a new separate guardrail.
I think this is probably worth a quick poll on the dev list.
By the way, this threshold is not using the guardrails framework. We have had
CASSANDRA-17193 open for a while to port it to guardrails.
> Batch size guardrail ignores primary key size
> ---------------------------------------------
>
> Key: CASSANDRA-19413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19413
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Guardrails
> Reporter: Szymon Miezal
> Assignee: Szymon Miezal
> Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> {color:#1f2328}The size of a mutation does not consider the primary key size.
> In the context of BATCHed mutations, this means that INSERTs, DELETEs, and
> UPDATEs for tables with a simple PRIMARY KEY and no clustering columns would
> be equal to zero (or almost zero depending on the version). Consequently, the
> batch_size_fail_threshold_in_kb has no effect for such tables, and it cannot
> protect the cluster from being overloaded.{color}
> {color:#1f2328}A test that reproduces the problem in 3.11 -
> [https://github.com/szymon-miezal/cassandra/commit/50b27c1e9030ce5ace6a6486a9876493c4ad41ae#diff-8cb249caec219439da461a4369f20530bb7d6cc0467c7e46f16288e22b574e61R43]
> {color}
> {color:#1f2328}There are a few ways it could be solved:{color}
> * {color:#1f2328}Modifying the existing batch_size_fail_threshold_in_kb to
> take into account the primary keys size (it has the disadvantage of changing
> the semantic of the guardrail thus introducing a regression).{color}
> * {color:#1f2328}Adding a new guardrail e.g.
> batch_size_with_pk_fail_threshold_in_kb that is going to be calculated taking
> primary key into account.{color}
> * Adding a -D switch that by default would be {{false}}{color:#1f2328}
> meaning that in case the new formula (which takes PK into account) yields
> value over the error threshold it will gracefully tell us about it in an
> additional log message. Changing the flag value to
> {color}{{true}}{color:#1f2328} would be equivalent to the new formula and
> error will be thrown in case we get over the threshold.{color}
> {{{color:#1f2328}I have a preference for going with an option that adds a new
> guardrail.{color}}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
