[
https://issues.apache.org/jira/browse/CASSANDRA-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRA-15696:
-----------------------------------
Description:
When ideal_consistency_level is set (CASSANDRA-13289), we currently increment a
counter if a request doesn’t meet the consistency level specified in the
configuration (or through JMX).
At the moment, we increment the counter if the query was successful or not. I
think it would be slightly better if we only incremented the counter if the
ideal CL wasn’t achieved but the query’s CL was met.
The original JIRA, stated the following as an objective:
{quote}If your application writes at LOCAL_QUORUM how often are those writes
failing to achieve EACH_QUORUM at other data centers. If you failed your
application over to one of those data centers roughly how inconsistent might it
be given the number of writes that didn't propagate since the last incremental
repair?
{quote}
The main benefit to the JIRA was to set a CL higher than the CL being used, and
to track how often we weren’t able to hit that CL despise hitting the
underlying CL. We should only increment the counter in a case where we were
able to meet the query provided consistency but were unable to meet the ideal
consistency level.
was:
When ideal_consistency_level is set (CASSANDRA-13289), we currently increment a
counter if a request doesn’t use the consistency level specified in the
configuration (or through JMX).
At the moment, we increment the counter if the query was successful or not. I
think it would be slightly better if we only incremented the counter if the
ideal CL wasn’t achieved but the query’s CL was met.
The original JIRA, stated the following as an objective:
{quote}
If your application writes at LOCAL_QUORUM how often are those writes failing
to achieve EACH_QUORUM at other data centers. If you failed your application
over to one of those data centers roughly how inconsistent might it be given
the number of writes that didn't propagate since the last incremental repair?
{quote}
The main benefit to the JIRA was to set a CL higher than the CL being used, and
to track how often we weren’t able to hit that CL despise hitting the
underlying CL. We should only increment the counter in a case where we were
able to meet the query provided consistency but were unable to meet the ideal
consistency level.
> Only track ideal CL failure when request CL is met
> --------------------------------------------------
>
> Key: CASSANDRA-15696
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15696
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
> Reporter: Jon Haddad
> Assignee: Jon Haddad
> Priority: Normal
>
> When ideal_consistency_level is set (CASSANDRA-13289), we currently increment
> a counter if a request doesn’t meet the consistency level specified in the
> configuration (or through JMX).
> At the moment, we increment the counter if the query was successful or not. I
> think it would be slightly better if we only incremented the counter if the
> ideal CL wasn’t achieved but the query’s CL was met.
> The original JIRA, stated the following as an objective:
> {quote}If your application writes at LOCAL_QUORUM how often are those writes
> failing to achieve EACH_QUORUM at other data centers. If you failed your
> application over to one of those data centers roughly how inconsistent might
> it be given the number of writes that didn't propagate since the last
> incremental repair?
> {quote}
> The main benefit to the JIRA was to set a CL higher than the CL being used,
> and to track how often we weren’t able to hit that CL despise hitting the
> underlying CL. We should only increment the counter in a case where we were
> able to meet the query provided consistency but were unable to meet the ideal
> consistency level.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]