Had a similar need early and have been trying to solve it. Looking forward
to this patch.
Brad Schoening (Jira) 于2023年3月8日 周三下午12:15写道：
>
> [
> https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Brad Schoening
I forgot to remove the last paragraph. We really do some queries with QUORUM on
system_auth.
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/CassandraRoleManager.java#L277-L291
From: Miklosovic, Stefan
Sent: Tuesday,
I am forwarding the message Ben Slater wrote me personally and asked me to post
it. He has some problems with the subscription to this mailing list with his
email.
Very uncommon in my experience – my guess would be at most 2 to 3 cluster out
of the few hundred that we manage.
Also picking up
I'm not sure if this recommendation is still valid (or ever was) but it's
not uncommon to have higher RF on system_auth keyspaces, where it would be
quite dramatic to hit this bug on the loss of a properly configured rack
for RF=3.
On Tue, Mar 7, 2023 at 2:40 PM Jeff Jirsa wrote:
> Anyone have
Thanks Benjamin, please, find below my comments.
"It is not necessarily a problem as long as we do get an issue with the
Modules boundaries and their access. For me it needs to be looked at on a
case by case basis."
We can still use the --add-opens/add-exports with Java 17(I mentioned I
added
Anyone have stats on how many people use RF > 3 per dc? (I know what it looks like in my day job but I don’t want to pretend it’s representative of the larger community) I’m a fan of fixing this but I do wonder how common this is in the wild. On Mar 7, 2023, at 9:12 AM, Derek Chen-Becker wrote:I
I am glad more people joined and expressed their opinions after my last e-mail.
It seems to me that there is a consensus in having it fixed directly in NTS and
make it little bit more smart about the replica placement but we should still
have a way how to do it "the old way".
There is a lot of
Right, why I said we should make NTS do the right thing, rather than throwing a
warning. Doing the right thing, and not getting a warning, is the best
behavior.
> On Mar 7, 2023, at 11:12 AM, Derek Chen-Becker wrote:
>
> I think that the warning would only be thrown in the case where a
> I think it would be a worse experience to not warn and let the user
discover later when they can't write at QUORUM.
Agree.
Should we add a note in the cassandra.yaml comments as well? Maybe in the
spot where default_keyspace_rf is defined? On the other hand, that section
is pretty "wordy"
I think that the warning would only be thrown in the case where a
potentially QUORUM-busting configuration is used. I think it would be a
worse experience to not warn and let the user discover later when they
can't write at QUORUM.
Cheers,
Derek
On Tue, Mar 7, 2023 at 9:32 AM Jeremiah D Jordan
I agree with Paulo, it would be nice if we could figure out some way to make
new NTS work correctly, with a parameter to fall back to the “bad” behavior, so
that people restoring backups to a new cluster can get the right behavior to
match their backups.
The problem with only fixing this in a
My view is that if this is a pretty serious bug. I wonder if transactional
metadata will make it possible to safely fix this for users without rebuilding
(only via opt-in, of course).
> On 7 Mar 2023, at 15:54, Miklosovic, Stefan
> wrote:
>
> Thanks everybody for the feedback.
>
> I think
Yes and thank you!
On Tue, 7 Mar 2023 at 10:28, Brandon Williams wrote:
> Yes.
>
> Kind Regards,
> Brandon
>
> On Tue, Mar 7, 2023 at 9:14 AM Miklosovic, Stefan
> wrote:
> >
> > Hi list,
> >
> > I want to highlight this ticket (1). I was waiting for trunk being on
> version "5.0" officially so
Thanks everybody for the feedback.
I think that emitting a warning upon keyspace creation (and alteration) should
be enough for starters. If somebody can not live without 100% bullet proof
solution over time we might choose some approach from the offered ones. As the
saying goes there is no
Yes.
Kind Regards,
Brandon
On Tue, Mar 7, 2023 at 9:14 AM Miklosovic, Stefan
wrote:
>
> Hi list,
>
> I want to highlight this ticket (1). I was waiting for trunk being on version
> "5.0" officially so we can get rid of this compaction strategy which was
> deprecated in 3.8. If we waited one
>
> Are people OK with the removal of DTCS in 5.0?
>
Yes.
Hi list,
I want to highlight this ticket (1). I was waiting for trunk being on version
"5.0" officially so we can get rid of this compaction strategy which was
deprecated in 3.8. If we waited one major with deprecated strategy (4.0), I
think it is eligible for the actual deletion in the next
> Is it right to assume that we need to address this first in order to
implement 18102? If we leave it as it is and we implement vtable with
"unique snapshot name globally" in mind and we design that vtable like
that, until we fix this issue, snapshots would be overwritten on top of
each other if
On Tue, 7 Mar 2023 at 11:20, Sam Tunnicliffe wrote:
> Currently, we anticipate CEP-21 being in a mergeable state around late
> July/August.
>
For me this is a more important reason to delay the branch date than
CEP-15, it being such a foundational change. Also, this is the first
feedback we've
Currently, we anticipate CEP-21 being in a mergeable state around late
July/August. We're intending to push a feature branch with an implementation
covering much of the core functionality to the ASF repo this week. Doing so
will obviously help us get a better idea of the remaining work as we
I agree too. Given the fact that the method checking the uniqueness of a
snapshot name was implemented first, it seems to me that the second method
which is not checking it just forgot to do that rather than intentionally doing
it like that.
Is it right to assume that we need to address this
21 matches
Mail list logo
