[ 
https://issues.apache.org/jira/browse/CASSANDRA-20843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18014671#comment-18014671
 ] 

Stefan Miklosovic commented on CASSANDRA-20843:
-----------------------------------------------

[~maedhroz] by the way, these are actually not _guardrails_. They do not 
integrate with guardrails framework. I wonder if this was done on purpose or 
not as it is used in DataResolver etc. which might be performance sensitive. 
The easiest job is to just change the comments and any traces of 
{{cached_replica_rows_...}} as OP requires and move on.

> Replica filtering guardrail needs a change in the yaml
> ------------------------------------------------------
>
>                 Key: CASSANDRA-20843
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-20843
>             Project: Apache Cassandra
>          Issue Type: Bug
>          Components: Documentation
>            Reporter: Paul Ayers
>            Priority: Normal
>              Labels: 5.0.5
>
> In the Cassandra 5 cassandra.yaml, we have the following guardrail section:
> {code:java}
> # Filtering and secondary index queries at read consistency levels above 
> ONE/LOCAL_ONE use a
> # mechanism called replica filtering protection to ensure that results from 
> stale replicas do
> # not violate consistency. (See CASSANDRA-8272 and CASSANDRA-15907 for more 
> details.) This
> # mechanism materializes replica results by partition on-heap at the 
> coordinator. The more possibly
> # stale results returned by the replicas, the more rows materialized during 
> the query.
> replica_filtering_protection:
>     # These thresholds exist to limit the damage severely out-of-date 
> replicas can cause during these
>     # queries. They limit the number of rows from all replicas individual 
> index and filtering queries
>     # can materialize on-heap to return correct results at the desired read 
> consistency level.
>     #
>     # "cached_replica_rows_warn_threshold" is the per-query threshold at 
> which a warning will be logged.
>     # "cached_replica_rows_fail_threshold" is the per-query threshold at 
> which the query will fail.
>     #
>     # These thresholds may also be adjusted at runtime using the 
> StorageService mbean.
>     #
>     # If the failure threshold is breached, it is likely that either the 
> current page/fetch size
>     # is too large or one or more replicas is severely out-of-sync and in 
> need of repair.
>     cached_rows_warn_threshold: 2000
>     cached_rows_fail_threshold: 32000
> {code}
> This is confusing for some as we had a customer attempt to configure 
> cached_replica_rows_warn_threshold and cached_replica_rows_fail_threshold in 
> addition to the actual parameters. We should update the wording so the 
> description matches the parameters.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to