Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

, at 4:06 PM, Yifan Cai wrote: >>> +1 (nb) >>> >>> >>> >>> *From:* Ariel Weisberg >>> *Sent:* Tuesday, May 6, 2025 12:59:09 PM >>> *To:* Claude Warren, Jr >>> *Subject:* Re: [DISCUSS] CEP-46 Finish Transient Replication/W

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 (nb) > On May 6, 2025, at 1:19 PM, Josh McKenzie wrote: > > +1 > > On Tue, May 6, 2025, at 4:06 PM, Yifan Cai wrote: >> +1 (nb) >> >> >> >> From: Ariel Weisberg >> Sent: Tuesday, May 6, 2025 12:59:09 PM >> To: Claude Warr

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 On Tue, May 6, 2025, at 4:06 PM, Yifan Cai wrote: > +1 (nb) > > > > *From:* Ariel Weisberg > *Sent:* Tuesday, May 6, 2025 12:59:09 PM > *To:* Claude Warren, Jr > *Subject:* Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses > > Hi, > > On

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 (nb) From: Ariel Weisberg Sent: Tuesday, May 6, 2025 12:59:09 PM To: Claude Warren, Jr Subject: Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses Hi, On Sun, May 4, 2025, at 4:57 PM, Jordan West wrote: I’m generally supportive. The concept is one

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

Hi, On Sun, May 4, 2025, at 4:57 PM, Jordan West wrote: > I’m generally supportive. The concept is one that I can see the benefits of > and I also think the current implementation adds a lot of complexity to the > codebase for being stuck in experimental mode. It will be great to have a > more

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 > On May 6, 2025, at 10:53 AM, Dmitry Konstantinov wrote: > > +1 (nb) > > On Tue, 6 May 2025 at 17:32, Aleksey Yeshchenko > wrote: >> +1 >> >>> On 5 May 2025, at 23:24, Blake Eggleston >> > wrote: >>> >>> As mutation tracking relates

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 (nb) On Tue, 6 May 2025 at 17:32, Aleksey Yeshchenko wrote: > +1 > > On 5 May 2025, at 23:24, Blake Eggleston wrote: > > As mutation tracking relates to existing backup systems that account for > repaired vs unrepaired sstables, mutation tracking will continue to promote > sstables to repair

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 > On 5 May 2025, at 23:24, Blake Eggleston wrote: > > As mutation tracking relates to existing backup systems that account for > repaired vs unrepaired sstables, mutation tracking will continue to promote > sstables to repaired once we know they contain data that has been fully > reconcile

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 (nb)

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

As mutation tracking relates to existing backup systems that account for repaired vs unrepaired sstables, mutation tracking will continue to promote sstables to repaired once we know they contain data that has been fully reconciled. The main difference is that they won’t be promoted as part of a

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

Consistent backup/restore is a fundamentally hard and unsolved problem for Cassandra today (without any of the mentioned features). In particular, we break the real-time guarantee of the linearizability property (most notably for LWTs) between partitions for any backup/restore process today. Fi

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

It took me a bit to wrap my head around how this works, but now that I think I understand the idea, it sounds like a solid improvement. Being able to achieve the same results as quorum but costing 1/3 less is a *big deal* and I know several teams that would be interested. One thing I'm curious ab

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

This sounds like a modern feature that will benefit a lot of folks in cutting storage costs, particularly in large deployments. I'd like to see a note on the CEP about documentation overhead as this is an important feature to communicate correctly, but that's just a nit. +1 on moving forward with

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

I’m generally supportive. The concept is one that I can see the benefits of and I also think the current implementation adds a lot of complexity to the codebase for being stuck in experimental mode. It will be great to have a more robust version built on a better approach. On Sun, May 4, 2025 at 0

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 This is an obviously good feature for operators that are storage-bound in multi-DC deployments but want to retain their latency characteristics during node maintenance. Log replicas are the right approach. > On 3 May 2025, at 23:42, sc...@paradoxica.net wrote: > > Hey everybody, bumping th

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

Hey everybody, bumping this CEP from Ariel in case you'd like some weekend reading. We’d like to finish witnesses and bring them out of “experimental” status now that Transactional Metadata and Mutation Tracking provide the building blocks needed to complete them. Witnesses are part of a famil

[DISCUSS] CEP-46 Finish Transient Replication/Witnesses

Hi all, The CEP is available here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=353601959 We would like to propose CEP-46: Finish Transient Replication/Witnesses for adoption by the community. CEP-46 would rename transient replication to witnesses and leverage mutation trac