Re: [VOTE] CEP-45: Mutation Tracking

[guo Maxwell]

+1
Dmitry Konstantinov 于2025年2月5日 周三上午6:04写道：

> +1 (nb)
>
> On Tue, 4 Feb 2025 at 22:00, Abe Ratnofsky  wrote:
>
>> +1 (nb)
>
>
>>
>
> --
> Dmitry Konstantinov
>

Re: [VOTE] CEP-45: Mutation Tracking

[Doug Rohrer]

+1

Thanks!

Doug

> On Feb 3, 2025, at 1:33 PM, Blake Eggleston  wrote:
> 
> Hi dev@,
> 
> I’d like to start the voting for CEP-45: Mutation Tracking
> 
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
> Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m863ofggdjc81
> 
> The vote will be open for 72 hours. A vote passes if there are at least 3 
> binding +1s and no binding vetoes.
> 
> Thanks,
> Blake Eggleston

Re: 【DISCUSS】What is the current status of triggers in Cassandra ?

[Sam Tunnicliffe]

This is really a bug with the current implementation of CreateTriggerStatement 
and I've filed CASSANDRA-20287 to address it. 

Thanks, 
Sam

> On 3 Feb 2025, at 21:06, Štefan Miklošovič  wrote:
> 
> Correct, snapshotting is the way to go here via nodetool cms snapshot 
> 
> But, you see? One more "problem" ... I bet my boots that in the majority of 
> cases this will be forgotten. Then we would need to put that JAR back just to 
> boot the cluster for the sake of snapshotting it. 
> 
> On Mon, Feb 3, 2025 at 9:58 PM Abe Ratnofsky  wrote:
> AFAIK the TCM replay issue you're describing (something is created and 
> dropped during replay, fails if can't create) applies to custom types and a 
> few other things, and one way around it is CMS snapshotting so replay doesn't 
> start at epoch 0; it wouldn't be safe to remove the trigger from the 
> classpath until the trigger drop epoch has been included in a snapshot: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-SnapshottingMetadataLog
> 
> I also think it's reasonable to not include triggers (or other custom fields) 
> in the clone, but if users need to sort out what parts of their original 
> table were copied to their clone it's not as convenient to have a separate 
> command for it.

Re: [VOTE] CEP-45: Mutation Tracking

[Josh McKenzie]

+1

On Mon, Feb 3, 2025, at 1:33 PM, Blake Eggleston wrote:
> Hi dev@,
> 
> I’d like to start the voting for CEP-45: Mutation Tracking
> 
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
> Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m863ofggdjc81
> 
> The vote will be open for 72 hours. A vote passes if there are at least 3 
> binding +1s and no binding vetoes.
> 
> Thanks,
> Blake Eggleston

Re: [VOTE] CEP-45: Mutation Tracking

[Francisco Guerrero]

+1

On 2025/02/04 21:54:06 Aleksey Yeshchenko wrote:
> +1
> 
> > On 4 Feb 2025, at 21:39, Bernardo Botella  
> > wrote:
> > 
> > +1 (nb)
> > 
> >> On Feb 4, 2025, at 12:34 PM, Dinesh Joshi  wrote:
> >> 
> >> +1
> >> 
> >> On Mon, Feb 3, 2025 at 10:35 AM Blake Eggleston  >> > wrote:
> >>> Hi dev@,
> >>> 
> >>> I’d like to start the voting for CEP-45: Mutation Tracking
> >>> 
> >>> Proposal: 
> >>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
> >>> Discussion: 
> >>> https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m863ofggdjc81
> >>> 
> >>> The vote will be open for 72 hours. A vote passes if there are at least 3 
> >>> binding +1s and no binding vetoes.
> >>> 
> >>> Thanks,
> >>> Blake Eggleston
> > 
> 
> 

Re: [VOTE] CEP-45: Mutation Tracking

[Abe Ratnofsky]

+1 (nb)

Re: [VOTE] CEP-45: Mutation Tracking

[Aleksey Yeshchenko]

+1

> On 4 Feb 2025, at 21:39, Bernardo Botella  
> wrote:
> 
> +1 (nb)
> 
>> On Feb 4, 2025, at 12:34 PM, Dinesh Joshi  wrote:
>> 
>> +1
>> 
>> On Mon, Feb 3, 2025 at 10:35 AM Blake Eggleston > > wrote:
>>> Hi dev@,
>>> 
>>> I’d like to start the voting for CEP-45: Mutation Tracking
>>> 
>>> Proposal: 
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
>>> Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m863ofggdjc81
>>> 
>>> The vote will be open for 72 hours. A vote passes if there are at least 3 
>>> binding +1s and no binding vetoes.
>>> 
>>> Thanks,
>>> Blake Eggleston
> 

Re: [VOTE] CEP-45: Mutation Tracking

[Dmitry Konstantinov]

+1 (nb)

On Tue, 4 Feb 2025 at 22:00, Abe Ratnofsky  wrote:

> +1 (nb)
>


-- 
Dmitry Konstantinov

Re: [DISCUSS] Snapshots outside of Cassandra data directory

[Jon Haddad]

Fwiw, I don't have a problem with using a shell script.  In the email I sent, I 
was trying to illustrate how getting to exploiting a shell vulnerability 
essentially requires a system that's been completely compromised already, 
either through JMX or through CQL (assuming we can update configs via CQL).

If someone wanted to do a Java version of the archiving command, I think that's 
fine, but there's going to be a lot of valid use cases that aren't covered by 
it.  I think a lot of operators will just want to be able to pop in some shell 
and be done with it.  If I'm going to either write a whole bunch of java or 
take 3 minutes to call `rclone`, I'm definitely calling rclone.

Overall, I like the idea of having a post-snapshot callback.  I think the Java 
version lets people do it in Java, and also leaves the possibility for people 
do it in shell, so it's probably the better fit.

Jon

On 2025/01/23 16:25:01 Štefan Miklošovič wrote:
> I feel uneasy about executing scripts from Cassandra. Jon was talking about
> this here (1) as well. I would not base this on any shell scripts /
> commands executions. I think nothing beats pure Java copying files to a
> directory ...
> 
> (1) https://lists.apache.org/thread/jcr3mln2tohbckvr8fjrr0sq0syof080
> 
> On Thu, Jan 23, 2025 at 5:16 PM Jeremiah Jordan 
> wrote:
> 
> > For commit log archiving we already have the concept of “commands” to be
> > executed.  Maybe a similar concept would be useful for snapshots?  Maybe a
> > new “user snapshot with command” nodetool action could be added.  The
> > server would make its usual hard links inside a snapshot folder and then it
> > could shell off a new process running the “snapshot archiving command”
> > passing it the directory just made.  Then what ever logic wanted could be
> > implemented in the command script.  Be that copying to S3, or copying to a
> > folder on another mount point, or what ever the operator wants to happen.
> >
> > -Jeremiah
> >
> > On Jan 23, 2025 at 7:54:20 AM, Štefan Miklošovič 
> > wrote:
> >
> >> Interesting, I will need to think about it more. Thanks for chiming in.
> >>
> >> On Wed, Jan 22, 2025 at 8:10 PM Blake Eggleston 
> >> wrote:
> >>
> >>> Somewhat tangential, but I’d like to see Cassandra provide a backup
> >>> story that doesn’t involve making copies of sstables. They’re constantly
> >>> rewritten by compaction, and intelligent backup systems often need to be
> >>> able to read sstable metadata to optimize storage usage.
> >>>
> >>> An interface purpose built to support incremental backup and restore
> >>> would almost definitely be more efficient since it could account for
> >>> compaction, and would separate operational requirements from storage layer
> >>> implementation details.
> >>>
> >>> On Jan 22, 2025, at 2:33 AM, Štefan Miklošovič 
> >>> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Jan 22, 2025 at 2:21 AM James Berragan 
> >>> wrote:
> >>>
>  I think this is an idea worth exploring, my guess is that even if the
>  scope is confined to just "copy if not exists" it would still largely be
>  used as a cloud-agnostic backup/restore solution, and so will be shaped
>  accordingly.
> 
>  Some thoughts:
> 
>  - I think it would be worth exploring more what the directory structure
>  looks like. You mention a flat directory hierarchy, but it seems to me it
>  would need to be delimited by node (or token range) in some way as the
>  SSTable identifier will not be unique across the cluster. If we do need 
>  to
>  delimit by node, is the configuration burden then on the user to mount
>  individual drives to S3/Azure/wherever to unique per node paths? What do
>  they do in the event of a host replacement, backup to a new empty
>  directory?
> 
> >>>
> >>> It will be unique when "uuid_sstable_identifiers_enabled: true", even
> >>> across the cluster. If we worked with "old identifiers" too, these are
> >>> indeed not unique (even across different tables in the same node). I am 
> >>> not
> >>> completely sure how far we want to go with this, I don't have a problem
> >>> saying that we support this feature only with
> >>> "uuid_sstable_identifiers_enabled: true". If we were to support the older
> >>> SSTable identifier naming as well, that would complicate it more. Esop's
> >>> directory structure of a remote destination is here:
> >>>
> >>>
> >>> https://github.com/instaclustr/esop?tab=readme-ov-file#directory-structure-of-a-remote-destination
> >>>
> >>> and how the content of the snapshot's manifest looks just below it.
> >>>
> >>> We may go with hierarchical structure as well if this is evaluated to be
> >>> a better approach. I just find flat hierarchy simpler. We can not have 
> >>> flat
> >>> hierarchy with old / non-unique identifiers so we would need to find a way
> >>> how to differentiate one SSTable from another, which naturally leads to
> >>> them being placed in keyspace/table/sstable hierarchy but I do not want 

Re: [VOTE] CEP-45: Mutation Tracking

[Bernardo Botella]

+1 (nb)

> On Feb 4, 2025, at 12:34 PM, Dinesh Joshi  wrote:
> 
> +1
> 
> On Mon, Feb 3, 2025 at 10:35 AM Blake Eggleston  > wrote:
>> Hi dev@,
>> 
>> I’d like to start the voting for CEP-45: Mutation Tracking
>> 
>> Proposal: 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
>> Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m863ofggdjc81
>> 
>> The vote will be open for 72 hours. A vote passes if there are at least 3 
>> binding +1s and no binding vetoes.
>> 
>> Thanks,
>> Blake Eggleston

Re: [VOTE] CEP-45: Mutation Tracking

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Feb 3, 2025 at 12:35 PM Blake Eggleston  wrote:
>
> Hi dev@,
>
> I’d like to start the voting for CEP-45: Mutation Tracking
>
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
> Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m863ofggdjc81
>
> The vote will be open for 72 hours. A vote passes if there are at least 3 
> binding +1s and no binding vetoes.
>
> Thanks,
> Blake Eggleston

Re: [VOTE] CEP-45: Mutation Tracking

[Dinesh Joshi]

+1

On Mon, Feb 3, 2025 at 10:35 AM Blake Eggleston 
wrote:

> Hi dev@,
>
> I’d like to start the voting for CEP-45: Mutation Tracking
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
> Discussion:
> https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m863ofggdjc81
>
> The vote will be open for 72 hours. A vote passes if there are at least 3
> binding +1s and no binding vetoes.
>
> Thanks,
> Blake Eggleston
>