I'm 100% in favor of repair being part of the core DB, not the sidecar. The current (and past) state of things where running the DB correctly *requires* running a separate process (either community maintained or official C* sidecar) is incredibly painful for folks. The idea that your data integrity needs to be opt-in has never made sense to me from the perspective of either the product or the end user.
I've worked with way too many teams that have either configured this incorrectly or not at all. Ideally Cassandra would ship with repair built in and on by default. Power users can disable if they want to continue to maintain their own repair tooling for some reason. Jon On 2023/07/24 20:44:14 German Eichberger via dev wrote: > All, > > We had a brief discussion in [2] about the Uber article [1] where they talk > about having integrated repair into Cassandra and how great that is. I > expressed my disappointment that they didn't work with the community on that > (Uber, if you are listening time to make amends 🙂) and it turns out Joey > already had the idea and wrote the code [3] - so I wanted to start a > discussion to gauge interest and maybe how to revive that effort. > > Thanks, > German > > [1] > https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/ > [2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619 > [3] https://issues.apache.org/jira/browse/CASSANDRA-14346 >
