Caleb Rackliffe created CASSANDRA-18732:
-------------------------------------------
Summary: Baseline Diagnostic vtables for Accord
Key: CASSANDRA-18732
URL: https://issues.apache.org/jira/browse/CASSANDRA-18732
Project: Cassandra
Issue Type: Improvement
Components: Accord, Observability/Metrics
Reporter: Caleb Rackliffe
In addition to JMX-based metrics, there are bits of diagnostic information for
Accord that we should consider exposing through vtables:
1.) We should ensure that coordinator-level CQL transactions and the local
reads and writes they spawn are visible to the existing {{QueriesTable}} vtable.
The first may already just work. We may need to make some tweaks to
{{TxnNamedRead}} and {{TxnWrite}} for the local operations though.
({{CommandStore}} tasks are out of scope here, as they would probably be more
confusing than useful in {{QueriesTable}}?)
2.) A new vtable for pending commands for a key.
- Disable SELECT */require a partition key
- Might require partial back-port of stringifying table/partition key from
Accord to be correct
- ex. {{SELECT timestamps FROM myawesometable where ks=? and table=? and
partition_key=?}}
- Clustering can be the Accord timestamp elements, no further normal columns.
3.) A new vtable for command store-specific cache stats
- Gather via {{Store.execute()}} for correctness.
- Store id should be partition key (see {{AccordCommandStore}})
- hits, misses, total (maybe just throw out the keyspaces and coalesce ranges?)
4.) (Requires [~aweisberg]'s outstanding work) A new vtable for live migration
state
- {{TableMigrationState}} could be flattened into a row
- Is this already persisted? If so, why a new vtable?
5.) A vtable to expose {{accord.local.Node#coordinating()}} as a map
- ex. {{SELECT txn_id, type}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
