[
https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454701#comment-17454701
]
Ekaterina Dimitrova commented on CASSANDRA-17180:
-------------------------------------------------
[~smiklosovic] reached out to me in Slack to confirm the config because of all
latest ongoing discussions.
Adding my thoughts here for the others with a note that I haven't looked at the
patch itself, just saw his yaml config suggestion:
As part of CASSANDRA-15234 I just remove the need of unit suffix and give the
users the chance to specify the config with unit of their choice. There is
backward compatibility for the old way. This will be only on trunk. Now the
things that [~dcapwell] wants to add will be on top after CASSANDRA-15234.
They are still not fully shaped is my understanding. Maybe the only question is
do we plan to start introducing new features nested like this - under
_startup_checks_ or keep the current way of introducing them? I see guardrails
were committed that way so probably that is the plan, I am a bit lost too of
what is the common consensus now.
Reading your ticket - is this what you are trying to introduce:
startup_checks:
data_dirs:
enabled: true
gc_grace_seconds:
enabled: true
correct_rack:
enabled: true
heartbeat:
enabled: true
file: .cassandra-heartbeat
ignored_tables:
- ks1.tb1
- ks2.tb2
- ks3 // would ignore whole keyspace
One question on my mind - _gc_grace_seconds_ is {_}enabled/disabled{_}.
Normally we do config parameter names with unit suffix if we are going to
provide value and this might be confusing.
The format sounds reasonable, just maybe ignored_tables deviate a bit from
other config in our file.
For example:
excluded_keyspaces: system, system_schema, system_virtual_schema
> Implement heartbeat service to know last time Cassandra node was up
> -------------------------------------------------------------------
>
> Key: CASSANDRA-17180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17180
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As already discussed on ML, it would be nice to have a service which would
> periodically write timestamp to a file signalling it is up / running.
> Then, on the startup, we would read this file and we would determine if there
> is some table which gc grace is behind this time and we would fail the start
> so we would prevent zombie data to be likely spread around a cluster.
> https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
