I feel like we've had a very similar conversation (not so) recently:
https://lists.apache.org/thread.html/9952c419398a1a2f22e2887e3492f9d6899365f0ea7c2b68d6fbe0d4@%3Cuser.cassandra.apache.org%3E
Which led to the creation of this JIRA:
https://issues.apache.org/jira/browse/CASSANDRA-13645
On Wed,
I think this was how it was in the dark ages, with the wiki and all. I
believe the reason why they shifted to in-tree docs is that this way,
people who make changes to the code are more likely to make the
corresponding doc changes as well, and reviewers have it easier to ensure
docs are updated wit
Since this is basically driver syntactic sugar... Yes I'll try that.
On Wed, Mar 14, 2018 at 5:59 PM, Jonathan Haddad wrote:
> You could use a load balancing policy at the driver level to do what you
> want, mixed with the existing consistency levels as Jeff suggested.
>
> On Wed, Mar 14, 2018
You could use a load balancing policy at the driver level to do what you
want, mixed with the existing consistency levels as Jeff suggested.
On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller
wrote:
> But we COULD have CL2 write (for RF4)
>
> The extension to this idea is multiple backup/secondary rep
But we COULD have CL2 write (for RF4)
The extension to this idea is multiple backup/secondary replicas. So you
have RF5 or RF6 or higher, but still are performing CL2 against the
preferred first three for both read and write.
You could also ascertain the general write health of affected ranges be
Write at CL 3 and read at CL 2
--
Jeff Jirsa
> On Mar 14, 2018, at 2:40 PM, Carl Mueller
> wrote:
>
> Currently there is little use for RF4. You're getting the requirements of
> QUORUM-3 but only one extra backup.
>
> I'd like to propose something that would make RF4 a sort of more heavily
I also wonder if the state of hinted handoff can inform the validity of
extra replicas. Repair is mentioned in 7168.
On Wed, Mar 14, 2018 at 4:55 PM, Carl Mueller
wrote:
> For my reference: https://issues.apache.org/jira/browse/CASSANDRA-7168
>
>
> On Wed, Mar 14, 2018 at 4:46 PM, Ariel Weisber
For my reference: https://issues.apache.org/jira/browse/CASSANDRA-7168
On Wed, Mar 14, 2018 at 4:46 PM, Ariel Weisberg wrote:
> Hi,
>
> There is a JIRA for decoupling the size of the group size used for
> consensus with level of data redundancy. https://issues.apache.org/
> jira/browse/CASSANDR
Hi,
There is a JIRA for decoupling the size of the group size used for consensus
with level of data redundancy.
https://issues.apache.org/jira/browse/CASSANDRA-13442
It's been discussed quite a bit offline and I did a presentation on it at NGCC.
Hopefully we will see some movement on it soon.
Currently there is little use for RF4. You're getting the requirements of
QUORUM-3 but only one extra backup.
I'd like to propose something that would make RF4 a sort of more heavily
backed up RF3.
A lot of this is probably achievable with strictly driver-level logic, so
perhaps it would belong m
https://issues.apache.org/jira/browse/CASSANDRA-14313
For some reason I'm told by many committers that we should not have sets of
documentation for other versions than the current version in a tree for that
version. This has made it difficult, maybe impossible to have documentation
for all the
11 matches
Mail list logo
