Close. I'm suggesting that if you have RF4 or 5 or 6, you get to designate
a subset of three replicas that are strongly preferred. From this "virtual
subset/datacenter" if you do QUORUM against that subset, it just does n/2+1
of the subset. Updates are still sent to the non-primary replicas, and if
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,
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
10 matches
Mail list logo
