[CASSANDRA-18732] Baseline Diagnostic vtables for Accord

• Type: Improvement
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 5.x
• Component/s: Accord, Observability/Metrics
• Labels: pull-request-available
• Epic Link: CEP-15: Accord Beta
• Change Category: Operability
• Complexity: Normal
• Platform: All

Source Control Link

https://github.com/apache/cassandra/commit/f47364697f3352e17422a43e29c8dd4a4cc44448

Test and Documentation Plan

minor additions to check vtables in existing Accord tests

• Assignee: Caleb Rackliffe
• Reporter: Caleb Rackliffe

Authors

Caleb Rackliffe

Reviewers

Ariel Weisberg, David Capwell

• Created: 07/Aug/23 15:36
• Updated: 28/May/24 21:55
• Resolved: 28/May/24 21:55

Description

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

Issue Links

• is blocked by: CASSANDRA-19577 Queries are not visible to the "system_views.queries" virtual table at the coordinator level
• relates to: CASSANDRA-18580 Baseline Metrics for Accord Transactions
• links to: GitHub Pull Request #89
• links to: GitHub Pull Request #3305